Админы говорят, что это из-за памяти, т.к. proxmox забирает 25% от выделенного объема, т.е. 120+- гб на рдп ему не хватает, тоже и с 1с, 100гб ему не хватает - в связи с чем идёт перераспределение памяти текущих сессий и как следствие зависания и тормоза.
Добавлю ещё, что 4 потока это не так уж и много для серверного ОЗУ, а точнее мало... Проверьте, может планки ещё и не на разных потоках стоят, а линейно подключены и работают в 1 поток.
Никогда не оставляйте свои данные на хх.ру и хабре... Спамить всякие рекламы запарили, спам ящик уже переполнен. Реальных соискателей около нуля, только данные выкачивают... Хорошо если ещё кто в резерв добавит.
А вы hdmi в слот видеокарты поставили? Если в слот мат платы, есть вероятность, что используется интегрированная видеокарта. Так же в настройках биоса может стоять приоритет на интегрированную карту .
Вот в этой незавершённости и проблема. Новый класс то мы стерли, а основной остался в скрипте - это логично в концепции использования php как одноразового скрипта, но для демона, тогда теряется смысл использования spl_autoload_register(). Так как с таким же успехом можно просто напрямую инлюдить.
maksam07, не теряйтесь в сообщениях. Я вам уже писал в другой ветке комментариев, что в целом это нужно исключительно для завершённости кода, и что я просто нахожу странным что такого не предусмотрено, а то, что сам скрипт занимает на порядок меньше места, Сергей и здесь описал уже.
Причём частично такая функция реализовано в одну сторону, в композере, который подключает используемые классы, но не отключает их. А теперь представьте демона который обращается к композеру и всему, что через него загружено, сколько при этом демон php будет весить? Да в итоге столько же, сколько папка композера.
Сергей delphinpro, чтобы демон висел на фоне, а классы подгружал только тогда, когда нужны, и выгружал их когда больше не нужны, для того чтобы в фоне не висело сразу всё. Другая причина, чтобы полноценно использовать автолоадер для демона, а не просто загружать все скрипты, но и выгружать их.
Сергей delphinpro, Ну, по крайней мере мне так кажется, что это логично - отсекать неиспользуемые участки кода. op_cashe конечно хранит целые файлы, которые вообще хоть как-то используются, для их повторного использования. Но, если использовать php как демон, то как раз, чтобы не разрастался, потому что по итогу он просто всё откроет что есть, и смысла от автолоадера тогда нет.
maksam07, просто вопрос по сути простой... Есть такая возможность или нет? А здесь начинается: "Что за чушь", придираются к словам... Когда ответ отрицательный, почему-то не могут люди просто пропустить вопрос А ответить, что нет такой возможности, по сути тоже не правильно, потому что по сути она имеется, но нужно уже на более низком уровне решать вопрос. В данном случае думаю, что такой метод вообще никак не помешал бы. Но он в PHP, похоже, что не реализован.
Чтобы включить файл в скрипт, его надо сначала прочитать. Расскажите, что добавиться в скрипт из файла, который не читается? К словам придраться мастера, а из шаблонного мышления выйти - нет. По сути искал обратный автолоадер, обратную функцию "spl_autoload_register()". Сам автолоадер реализован хорошо, до момента когда нужно получить обратный эффект - Не дополнить скрипт, а разгрузить.
maksam07, благодарю, но ob_start влияет только на буфер, а через exec, proc_open или просто через удаленный доступ более вероятно, но хотелось бы именно "не выбиваться из текущего процесса". Ну, рано или поздно придём к этому... Автолоад с пространством имён ведь спроектировали, значит и обратный процесс не помешал бы.
maksam07, В любом случае для большинства проектов, даже пол мегабайта не надо... Вопрос простой: "имеется в php такой метод, или нет?", по поводу коротких сеансов php, поэтому и написал, чтобы не интересовались для чего? Не в первый раз уже с просто с таким сталкиваюсь, как и со множеством других проблем, которые решаются в пару методов, но этого никак нельзя было сделать, да и в целом, что-то для сообщества хабра вопросы сложные наверное, ломают стереотипы, шаблоны.
Добавлю ещё, что 4 потока это не так уж и много для серверного ОЗУ, а точнее мало... Проверьте, может планки ещё и не на разных потоках стоят, а линейно подключены и работают в 1 поток.