Мало оперативной памяти

Skull515 · 27 лютого 2019

Всем привет.

Есть сайт, он на VPS от timeweb, тариф Master (2х2,4ГГц + 1Гб RAM + 30Гб SSD) + панель Vesta. В магазине сейчас почти 10К товаров. Много атрибутов (десятки), много значений опций (в самой часто используемой - 163 значения, остальные до 20 примерно), но не так чтобы тысячи. В момент переноса на VPS было около 4К товаров и за период больше года выросло до 10К. Все было хорошо до 22.02.2019. Именно в этот день один из модулей пожаловался на недостаточный параметр max_input_vars (был 1000, выставил 3000), параметр был увеличен через php.ini, но изменения применяться не хотели и я написал в поддержку. Ответ пришел быстро - они переключили PHP на fcgid. Параметр применился, модуль перестал ругаться, все было хорошо, пока сайт не отвалился, примерно с такими ошибками.

Спойлер

Warning: mysqli::mysqli(): (HY000/2002): No such file or directory in /home/admin/web/kovrodel63.ru/public_html/system/library/db/mysqli.php on line 7

Warning: DB\MySQLi::__construct(): Couldn't fetch mysqli in /home/admin/web/kovrodel63.ru/public_html/system/library/db/mysqli.php on line 10

Их было много разных, но все они говорили о том, что отваливается БД. На сайте начали глючить работающие до этого модули, а oom-killer начал вырубать процессы, обеспечивая еще большую нестабильность.

Спойлер


Feb 22 09:45:36 129714 kernel: [306390.467603] Out of memory: Kill process 4566 (mysqld) score 254 or sacrifice child
Feb 22 09:57:46 129714 kernel: [307121.060409] Out of memory: Kill process 24325 (mysqld) score 186 or sacrifice child
Feb 22 10:00:41 129714 kernel: [307296.530136] Out of memory: Kill process 25013 (mysqld) score 153 or sacrifice child
Feb 22 10:00:41 129714 kernel: [307296.543038] Out of memory: Kill process 25065 (mysqld) score 153 or sacrifice child
Feb 22 10:13:19 129714 kernel: [308049.564726] Out of memory: Kill process 25306 (mysqld) score 182 or sacrifice child
Feb 22 10:17:33 129714 kernel: [308307.870903] Out of memory: Kill process 26223 (mysqld) score 184 or sacrifice child
Feb 22 10:19:32 129714 kernel: [308426.977586] Out of memory: Kill process 26632 (mysqld) score 150 or sacrifice child
Feb 22 10:20:15 129714 kernel: [308470.129196] Out of memory: Kill process 26723 (mysqld) score 133 or sacrifice child
Feb 22 10:20:15 129714 kernel: [308470.132765] Out of memory: Kill process 26765 (mysqld) score 133 or sacrifice child
Feb 22 10:20:42 129714 kernel: [308497.536011] Out of memory: Kill process 26912 (mysqld) score 123 or sacrifice child
Feb 22 10:20:42 129714 kernel: [308497.547424] Out of memory: Kill process 27035 (mysqld) score 123 or sacrifice child
Feb 22 10:21:03 129714 kernel: [308518.605264] Out of memory: Kill process 27047 (mysqld) score 123 or sacrifice child
Feb 22 10:21:11 129714 kernel: [308526.781409] Out of memory: Kill process 27104 (mysqld) score 119 or sacrifice child
Feb 22 10:21:25 129714 kernel: [308540.870749] Out of memory: Kill process 27157 (mysqld) score 118 or sacrifice child
Feb 22 13:38:12 129714 kernel: [320347.760793] Out of memory: Kill process 28345 (mysqld) score 196 or sacrifice child
Feb 22 15:16:17 129714 kernel: [326231.968084] Out of memory: Kill process 7932 (mysqld) score 191 or sacrifice child
Feb 22 15:18:21 129714 kernel: [326356.214597] Out of memory: Kill process 14359 (mysqld) score 161 or sacrifice child
Feb 22 15:18:21 129714 kernel: [326356.231584] Out of memory: Kill process 14408 (mysqld) score 161 or sacrifice child
Feb 22 15:20:55 129714 kernel: [326510.365680] Out of memory: Kill process 14464 (mysqld) score 167 or sacrifice child
Feb 22 15:20:55 129714 kernel: [326510.428241] Out of memory: Kill process 14568 (mysqld) score 167 or sacrifice child
Feb 22 15:21:44 129714 kernel: [326558.804967] Out of memory: Kill process 14829 (mysqld) score 132 or sacrifice child
Feb 22 15:21:44 129714 kernel: [326558.809526] Out of memory: Kill process 14882 (mysqld) score 132 or sacrifice child

Я обратился в поддержку, дескать, PHP переключили и понеслось. На что получил ответ о том, что да, SQL отваливается, детальнее разбирайся сам через htop, а про возможность увеличения потребления памяти после переключения PHP деликатно умолчали. Да, привожу график скачка по памяти, прямо после того как отписались из поддержки. Видим, что после этого просто вырос уровень потребления памяти, в один момент. На сайт ничего не залили, да и пользователей не набежало.

Сейчас сайт отваливается раз в сутки, что, конечно, не хорошо. После перезапуска сервера опять работает. Так же, заметил периодическую самовольную перезагрузку серверов: БД, FTP, файервол, почтовые - вроде ранее такого не было...

У меня есть ряд конкретных вопросов.

1. Верна ли догадка о том, что переход PHP на php-fcgid мог так пагубно повлиять на память, если вернуться обратно на на просто php, вернется ли память на прежний уровень расхода, но как тогда быть с php.ini и параметрами, тем же input_vars? Да PHP версии 5.6...

2. При таком кол-ве товаров возможно ли оптимизировать запросы, настроить сервер, еще что-то сделать, чтобы не увеличивать лимит RAM? Я думаю, что бесконечное увеличение RAM - не есть правильный путь для решения вопроса...

3. Я уверен, что среди участников форума найдется специалист, который поможет мне решить эти вопросы. Проведет диагностику, даст рекомендации, а после согласования цены и сами работы по оптимизации.

К сожалению моих познаний в сетевом администрировании явно не хватает, поэтому буду благодарен за любую помощь, в том числе и платную.

SunnRi · 27 лютого 2019

43 минуты назад, Skull515 сказал:

дескать, PHP переключили и понеслось.

А зачем? И на что?И что было перед этим?
Работает на апаче обычном?

43 минуты назад, Skull515 сказал:

PHP деликатно умолчали

Можете их дергать, пока с ушей кровь не потечёт.

При переходе на nginx + php у вас сразу увеличится потребление, в любом случае, но вы выигрываете в скорости обработки.
Так что тут все равно, как бы вы не хотели память добавить надо, еще хотя бы 512, но лучше 1гб добавьте.

У меня при 1000 товара (10-12 атрибутов, 2-3 опции у каждого) и в связке nginx + php (7.1) + opcache переодически падает тоже..и вырубает sql..И все это держится на уровне 600-700мб из 1гб.

После перехода с apache жор добавил примерно 200 мб

Змінено 27 лютого 2019 користувачем SunnRi

EvaSystems · 27 лютого 2019

max_input_vars должен меняться в любом случае, не зависимо от режима работы php. Единственное, что на разных режимах работы

его по-разному необходимо менять. Всё зависит от того, как у вас настроено. Вполне могла быть ситуация, что тот php.ini, в котором

вы пытались поменять, не был задействован в действующей конфигурации. Можете попробовать вернуться обратно, меняя значения

переменной уже в нужном месте. Собственно можете попробовать менять его через .htaccess даже.

Да, на текущем сервере можно провести настройку и попробовать снизить потребление памяти, но это повлияет на производительность,

которая и так низкая (стандартные настройки)... то, что должно работать в памяти, будет работать с диском и т.д.

По поводу режимов работы php,если что-то и менять, то переходить на nginx+php-fpm, т.е отказываться от использования apache.

Использовать всякие cgi/fcgid/fastcgi режимы в связке с apache лишено смысла (исключение составляют технические сложности, когда на

сервере, например, несколько версий php и одна уже используется в режиме mod_apache. Другие альтернативные версии при этом можно

запустить лишь в других режимах)

В идеале 1гб мало, такая конфигурация подходит лишь для разработки. Как я уже писал выше, стандартные настройки не обеспечивают

должную производительность, а если понижать значения, то будет только хуже. Да, вопрос стоял совсем в другом. Но, повторюсь,

в идеале 1гб памяти мало, я бы посоветовал увеличить немного, хотя бы до 2гб, чтобы можно было выделить память туда, куда это

действительно необходимо и повысить общую производительность вашего сервера.

Змінено 27 лютого 2019 користувачем EvaSystems

100napb · 27 лютого 2019

1 hour ago, Skull515 said:

У меня есть ряд конкретных вопросов.

1. Верна ли догадка о том, что переход PHP на php-fcgid мог так пагубно повлиять на память, если вернуться обратно на на просто php, вернется ли память на прежний уровень расхода, но как тогда быть с php.ini и параметрами, тем же input_vars? Да PHP версии 5.6...

2. При таком кол-ве товаров возможно ли оптимизировать запросы, настроить сервер, еще что-то сделать, чтобы не увеличивать лимит RAM? Я думаю, что бесконечное увеличение RAM - не есть правильный путь для решения вопроса...

3. Я уверен, что среди участников форума найдется специалист, который поможет мне решить эти вопросы. Проведет диагностику, даст рекомендации, а после согласования цены и сами работы по оптимизации.

Конкретные вопросы любят конкретных ответов:

1. Верно. Судя по описанной Вами ситуации, у Вас fcgi запускается через apache + mod_fastcgid. Так вот FastCGI - это лишь способ запуска php. Но php-fcgid действительно по-другому работает с памятью и отличается тем, что процесс php не завершаеся после обслуживания клиента\выполнения работы, а ждет нового. Таким образом, обработчик php при FastCGI запущен всегда, и нет нужды тратить время на его запуск - ему достаточно только выполнять полезную работу. И за это надо платить постоянным выделением памяти. Тот же php-fpm работает по-другому. Более экономно, что важно в Вашем случае )

2. Можно конечно. Проект не выглядит прямо супер-большим. И 1гб озу вполне должно хватить если не на супер-быструю, то на стабильную работу всех служб и сервисов - факт.
3. Есть такие ребята, конечно. Чуть выше, например очень годный совет от сразу двух: @Designer и @EvaSystems

У меня, например, громадный опыт работы базами данных, mysql - в том числе. Ну а с настройками веб-серверов уже приходится "дружить" за компанию, т.к. они почти всегда соседствуют с сервером БД и делят с ним ресурсы\вместе отвечают за итоговую стабильность и производительность проекта. Короче говоря, с удовольствием могу помочь настроить сервер БД должны образом, отпрофилировать и оптимизировать любые медленные запросы. Памяти всем хватит) Пишите, если интересно.

Змінено 27 лютого 2019 користувачем 100napb

Skull515 · 27 лютого 2019

45 минут назад, SunnRi сказал:

А зачем? И на что?И что было перед этим?
Работает на апаче обычном?

Да, на апаче, настройки в Vesta прилагаю картинку. Было php56.

48 минут назад, Designer сказал:

nginx + php-fpm

Честно говоря проблематично для меня сделать такой переход... знаний маловато...

Цитата

1гб памяти мало, я бы посоветовал увеличить, чтобы можно было выделить память туда, куда это действительно необходимо и повысить

общую производительность вашего сервера.

Вот в том то и вопрос, я могу сказать заказчику купить еще оперативы (правда сколько, 512 или больше...), но хотелось бы помимо этого "выделить память туда, куда это действительно необходимо и повысить общую производительность", как Вы правильно написали.

SunnRi · 27 лютого 2019

Мой личный совет

1. Переходим с apache на nginx + php - fpm + вместо 5.6 ставим 7.1,(!) но перед этим, уточните по всем модулям которые у вас стоят, поддерживаю ли они работу в 7.1

2. Добавьте минимум 512мб оперативной памяти, что бы быть уверенным.

3. Ставьте акселераторы php

4. Посмотрите на медленные логи, и по возможности оптимизируйте

5. Есственно проставьте индексы где они (!) нужны

6. Поработайте над уменьшением веса (картинки, css, js)

Если вы сделаете данные манипуляции, вы будет приятно удивлены Даже после после 1,3,6 пунктов)

UPD. В 2019 году быть без SSL - не правильно вовсе

Можно еще конечно сделать полный разгром по вашему каталогу и остальным моментам, но это уже совсем другая история....)

Змінено 27 лютого 2019 користувачем SunnRi

Skull515 · 27 лютого 2019

16 минут назад, 100napb сказал:

Верно. Судя по описанной Вами ситуации, у Вас fcgi запускается через apache + mod_fastcgid. Так вот FastCGI - это лишь способ запуска php. Но php-fcgid действительно по-другому работает с памятью и отличается тем, что процесс php не завершаеся после обслуживания клиента\выполнения работы, а ждет нового. Таким образом, обработчик php при FastCGI запущен всегда, и нет нужды тратить время на его запуск - ему достаточно только выполнять полезную работу. И за это надо платить постоянным выделением памяти. Тот же php-fpm работает по-другому. Более экономно, что важно в Вашем случае )

Я думаю решение вернуться на php56 не лучшее в моем случае...

6 минут назад, nikifalex сказал:

обратитесь к нормальному сисадмину и все проблемы сами собой решаться.

неужели никто еще не предложил свои услуги?

Буду рад выслушать предложения в личку, потому что почитав ответы я понял, что если я и осилю подобную оптимизацию, то потрачу уйму времени сил и не раз обрушу сайт, прежде чем добьюсь результата. Единственный момент - хотелось бы остаться на php5.6, не все модули потянут 7 версию...

Змінено 27 лютого 2019 користувачем Skull515

100napb · 27 лютого 2019

3 minutes ago, nikifalex said:

обратитесь к нормальному сисадмину и все проблемы сами собой решаться.

неужели никто еще не предложил свои услуги?

Хах)) С таким подходом не поспоришь.

Пожалуй, это очевидно, но почти все сообщения выше - это как оферта между строк, типа, "я готов помочь! и предлагаю свои услуги. Зацените - я компетентен". Просто эти предложения своих услуг не такие толстые ))

EvaSystems · 27 лютого 2019

6 минут назад, Skull515 сказал:

Вот в том то и вопрос, я могу сказать заказчику купить еще оперативы (правда сколько, 512 или больше...), но хотелось бы помимо этого "выделить память туда, куда это действительно необходимо и повысить общую производительность", как Вы правильно написали.

Подправил пост свой...

Ещё 1гб хотя бы, чтобы можно было развернуться. С грамотным распределением ресурсов могу помочь.

Имею множество отзывов на крупных и профильных форумах, в том числе и тут.

Yoda · 27 лютого 2019

Не увидел в постах специалистов нормальной экспертизы ситуации. К сожалению. Отзывы видимо пишут сами себе.

Ваша проблема очень простая попросите саппорт перевести режим работы php-fpm в ondemand и сделать swap 2gb. А также снизьте размер памяти на поток php до 128мб. На этом ваши проблемы закончатся. Все эти манипуляции может выполнить любой специалист саппорта хостинга.

Также не лишним будет выключить и убрать из автозагрузки демон Apache.

Слушать советы советчиков, которые только что их нагуглили в stack overflow себе дороже.

EvaSystems · 27 лютого 2019

21 минуту назад, Yoda сказал:

Не увидел в постах специалистов нормальной экспертизы ситуации. К сожалению. Отзывы видимо пишут сами себе.

Ваша проблема очень простая попросите саппорт перевести режим работы php-fpm в ondemand и сделать swap 2gb. А также снизьте размер памяти на поток php до 128мб. На этом ваши проблемы закончатся. Все эти манипуляции может выполнить любой специалист саппорта хостинга.

Также не лишним будет выключить и убрать из автозагрузки демон Apache.

Слушать советы советчиков, которые только что их нагуглили в stack overflow себе дороже.

Спойлер

Да уж... Ворвались толком не разобравшись в ситуации, обвинили всех в некомпетентности, а сами что?

Вы бы хоть тему прочитали внимательно... Сейчас вы как раз один из тех самых советчиков, о которых упоминали...

P.S прошу прощения за оффтоп, не смог пройти мимо)

Yoda · 27 лютого 2019

Только что, EvaSystems сказал:

Скрыть контент

Да уж... Ворвались толком не разобравшись в ситуации, обвинили всех в некомпетентности, а сами что?

Вы бы хоть тему прочитали внимательно... Сейчас вы как раз один из тех самых советчиков, о которых упоминали...

P.S прошу прощения за оффтоп, не смог пройти мимо)

Не смешите пожалуйста.

Я понимаю, что мощь отзывов на сторонних ресурсах давит на грудь.
Но к делу отношения это все не имеет.

Хотите можем поспорить на приличную денежную сумму, что мои рекомендации решат проблемы топик стартера и лишат его пустых финансовых потерь на оплату специалистов с отзывами на сторонних ресурсах.

EvaSystems · 27 лютого 2019

5 минут назад, Yoda сказал:

Не смешите пожалуйста.

Я понимаю, что мощь отзывов на сторонних ресурсах давит на грудь.
Но к делу отношения это все не имеет.

Хотите можем поспорить на приличную денежную сумму, что мои рекомендации решат проблемы топик стартера и лишат его пустых финансовых потерь на оплату специалистов с отзывами на сторонних ресурсах.

Спойлер

О боже... Прочитайте, пожалуйста, внимательно тему(отбросив при этом все предубеждения).

Это всё, что я хотел до вас донести, а не вступать с вами в словесные перепалки и, извиняюсь, мерятся размерами...

Yoda · 27 лютого 2019

Только что, EvaSystems сказал:

Скрыть контент

О боже... Прочитайте, пожалуйста, внимательно тему(отбросив при этом все предубеждения).

Это всё, что я хотел до вас донести, а не вступать с вами в словесные перепалки и, извиняюсь, мерятся размерами...

Что мне ещё нужно сделать?

Кстати смею заметить, мой пост был адресован не вам.

А также не услышал вашего ответа на мое предложение.

Давайте дальше либо конкретику и подтвердите ваши высказывания действием, либо не засоряейте эфир.

sitecreator · 27 лютого 2019

6 часов назад, SunnRi сказал:

При переходе на nginx + php у вас сразу увеличится потребление, в любом случае

Это обычно не так. При грамотной настройке не увеличивается.

Вы в принципе сами вольны выделять необходимые ресурсы. Назначать кол-во процессов php-fpm при старте и т.д.и т.п.

В режиме nginx + php возможны утечки памяти на некоторых версиях php, особенно если еще и ioncube присутствует.

Но с этим можно успешно бороться.

6 часов назад, Skull515 сказал:

2х2,4ГГц + 1Гб RAM

для двух ядер это мало.

память должна быть в приоритете, ядра - на втором месте.

вам надо бы от 2 Гиг память.

@Skull515 , если интересно, то обращайтесь.

Настроим наилучшим образом.

SunnRi · 27 лютого 2019

16 минут назад, sitecreator сказал:

Это обычно не так. При грамотной настройке не увеличивается.

Вы в принципе сами вольны выделять необходимые ресурсы. Назначать кол-во процессов php-fpm при старте и т.д.и т.п.

В режиме nginx + php возможны утечки памяти на некоторых версиях php, особенно если еще и ioncube присутствует.

Но с этим можно успешно бороться.

для двух ядер это мало.

память должна быть в приоритете, ядра - на втором месте.

вам надо бы от 2 Гиг память.

@Skull515 , если интересно, то обращайтесь.

Настроим наилучшим образом.

Но все равно, без "надфиля", увеличится ведь? т.е поставили nginx и пых и все

sitecreator · 27 лютого 2019

6 минут назад, SunnRi сказал:

т.е поставили nginx и пых и все

Скажем так, я с настройками по умолчанию не запускал. я про nginx+php-fpm

А с нужными настройками и при отсутствующем Апачи (за ненадобностью) в итоге расход памяти наоборот уменьшается.

Вот утечки памяти наблюдал для php-fpm. Это может создать впечатление, что расход памяти увеличился. Но это другое.

Причем наблюдал в php 7.0, но не наблюдал в php 5.6 при одинаковой конфигурации.

Это может быть связано как с самим движком php, так и с применением ioncube, представители которого официально подтверждали проблемы с утечкой и делали соответствующие исправления в последующих ioncube loader для устранения утечек.

Yoda · 28 лютого 2019

10 часов назад, sitecreator сказал:

Скажем так, я с настройками по умолчанию не запускал. я про nginx+php-fpm

А с нужными настройками и при отсутствующем Апачи (за ненадобностью) в итоге расход памяти наоборот уменьшается.

Вот утечки памяти наблюдал для php-fpm. Это может создать впечатление, что расход памяти увеличился. Но это другое.

Причем наблюдал в php 7.0, но не наблюдал в php 5.6 при одинаковой конфигурации.

Это может быть связано как с самим движком php, так и с применением ioncube, представители которого официально подтверждали проблемы с утечкой и делали соответствующие исправления в последующих ioncube loader для устранения утечек.

А я наблюдал сервера которые лежали после ваших настроек. Это ужас и кошмар. Если вдруг вы захотите возразить. То готов всегда доказать свои слова но при участии независимого жюри и с большими ставками. Крайне не рекомендую обращаться к данному исполнителю. Берёт деньги за воздух.

SunnRi · 28 лютого 2019

Я так понял, это сейчас тема у @Yoda всех помоями обливать.... При чем доказательства, если надо предоставить, то сразу 100-200-1000 баксов...И независимое жюри)
Смешно конечно)

Змінено 28 лютого 2019 користувачем SunnRi

Skull515 · 28 лютого 2019

Спасибо всем, кто откликнулся на мой пост! Я узнал для себя полезную информацию, а самое главное расширил список людей с кем можно посоветоваться по вопросам сетевого администрирования и оптимизации. Хочу отдельное спасибо сказать @100napb - он помог решить мои вопросы + сделал много чего сверх моих ожиданий - это приятно. Ну и самое главное на сервере теперь примерно 400Мб (+/-) свободной памяти, сайт стал работать быстрее, а покосившиеся модули пришли в норму! Я доволен результатом и готов рекомендовать @100napb как специалиста по решению подобных вопросов.

Вхід

Мало оперативной памяти

Recommended Posts

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Створіть аккаунт або увійдіть для коментування

Створити обліковий запис

Вхід

Зараз на сторінці 0 користувачів

Покупцям

Розробникам

Корисна інформація

Останні розширення

Important Information