Laravel по-русски
Laravel по-русски
Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Страницы 1
Друзья, доброго времени суток.
Написали мы тут веб-сервис многопоточный. Многопотоком управляет стандартный ларовский супервайзер. Потоков 1200. Через пару часов ОЗУ нашего сервака на 48 ГБ забивается и мы теряем над ним управление. Поэтому админ написал скрипт, который супервайзер раз в 2 часа по крону передергивает и все работает дальше нормально. Но это костыльный подход. Может кто-то тоже сталкивался с таким и нашел нормальное решение?
Не в сети
Мастер
Писарь
проблема в хотелках))) нестыкуемых с математикой.
php.ini обём выделяемой памяти (обычно сейчас 128мб) * 1200 = 153,6 гб.
я молчу, сколько кушает операционка, сколько кушает БД и сколько этих БД.
объяснил ?
Не в сети
МастерПисарь
не забываем, что обращение к БД так же создаёт всплеск использования памяти для создания временных таблиц в памяти для сортировок и джойнов всяких там.
проектировать подобные масштабные Проекты должны профи.
Вы, я вижу, только исполнители...
Не в сети
Для БД выделен другой сервер, для быстрого кеша на редисе третий, а вот бекенд крутится на том сервере где мы и наблюдаем такие проблемы. На счет 128Мб выделяемой памяти. Это что разве на один поток выделение происходит?
Не в сети
МастерПисарь
Для БД выделен другой сервер, для быстрого кеша на редисе третий, а вот бекенд крутится на том сервере где мы и наблюдаем такие проблемы. На счет 128Мб выделяемой памяти. Это что разве на один поток выделение происходит?
1. Уважаемый, какое отношение вы имеете к программированию на РНР ? Вопрос прямой, - ожидаю прямой ответ.
2. На исполнение (запуск приложения) выделяется конкретный лимит памяти, указанный в конфигурации языка. В данном случае в php.ini, директива `memory_limit`
Ниже ссылка для чтения.
; Maximum amount of memory a script may consume (128MB)
; http://php.net/memory-limit
memory_limit = 128M3. Рекомендую сначала немного по-администрировать *nix системы, чтобы понимать как оно всё работает внутри, а уже потом приниматься за программирование. Хотябы года 3-4... Иначе Вы будете задавать вопросы из группы "...да, капитан очевидность" и не понимать, почему с вами не разговаривают, либо разговаривают как с пятилетним.
Не в сети
Уважаемый, какое отношение вы имеете к программированию на РНР ? Вопрос прямой, - ожидаю прямой ответ.
Никакого. Я владелец веб-сервиса.
Ни сисадмин ни программер не понимают что происходит, поэтому пришлось вникать самому.
Не в сети
МастерПисарь
hzone пишет:Уважаемый, какое отношение вы имеете к программированию на РНР ? Вопрос прямой, - ожидаю прямой ответ.
Никакого. Я владелец веб-сервиса.
Ни сисадмин ни программер не понимают что происходит, поэтому пришлось вникать самому.
Окей, тогда прошу прощения за дерзости 
Короче я объяснил, что памяти в 4-8 раз больше надо для 1200 потоков.
делайте:
- либо 32мб/ на процесс рнр (при этом не факт что будет работать)
- либо ~300 потоков, и не советую играть хвостими добивая до потолка, результируя 308=идеально. Всегда понижайте до ближайших нулей _вниз_, а то будете чесать репу дальше, почему на 1199 потоке через 5 месяцев обвалилось и не вспомните эту тему даже.
Не в сети
Что интересно. У нас работало при 800 потоков без этого костыля, но нужно было поднять производительность и я попросил админа что-то придумать. Придумали костыль но подняли потоки до 1200)
За мысль с ограничением кол-ва памяти спасибо! Поковыряем эту переменную.
Не в сети
МастерПисарь
800 у вас работать будет до момента, когда в потоке не материализуется необходимость сбора статистики и, что самое страшное в вашем случае, генерации аналитики.
ваш предел при названных объёмах памяти 300 потоков в 40гб памяти, -4гб на бд, если она одна и 4гб на операционку, которая скорее всего х64.
Не в сети
МастерПисарь
+ у вас поток постоянный или с концом отработки, исполняемый по событию/времени ? если не постоянный, то после оптимизации кода/запросов к бд, вы сможете поднять кол-во таких потоков.
+ используйте метод рнр показывающий значения использования памяти (фактический и пиковый), где если пиковый превышает фактический более чем на 15%, то уже есть смысл оптимизировать код, а если на 25%+, то смотреть уже в запросы (в коде). параллельно подумать о б избавлении от "грязного чтения" данных бд в пользу расклеивания таблиц на статичные данные (редко изменяемые) и часто изменяемые, по разным таблицам, и склейки обоих во View которое и будет аггрегатором ваших необходимостей (только для чтения, писать в разделённые).
+ после чего начинайте ловить потоки, которые дольше всего работают над стандартными операциями и разбираться где проседания.
Изменено hzone (24.10.2016 19:01:37)
Не в сети
Страницы 1
Универсальная вики-разметка
Работает на FluxBB (перевод Laravel.ru)