Тормозит магазин. Что делать? (на самом деле решили)

[Yoda]

Вопрос для специалистов.

 

Есть магазин 80 000 товаров.

3500 посетителей в день.

3-5 глубина просмотра.

порядка 20-30к посещений ботов в сутки.

Время генерации страниц без каких-то левых модулей кеширования, "на холодную" в рамках 100-300мс.

Нагрузка на сервере на процессор в пределах допустимого, пик не более 30%.

Расход памяти в пик до 70%.

Медленных запросов в базу - 0.
Поиск реализован на sphinx  - тоже нагрузки создавать не может. 
Потенциальные дыры для ддоса закрыты. Настроено даже ограничение на всплески посещений с одного айпи средствами nginx.

Кеш в redis.

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

При этом регулярно, а особенно в моменты когда покупатели активно добавляют корзины/оформляют заказы, либо менеджеры залогиненные в админке работают с обработкой заказов наблюдаются нелинейные фризы на 7-10 секунд. В ночное время, когда нет активности покуапетелей, подобные зависания практически отсутсвуют. 
Еще раз подчеркну - медленных запросов нет. Тоесть ни к базе ни к серверу, ни к настройкам окружения нет претензий.

 

Что бы вы делали в этой ситуации?

 

 

 

[chukcha]

/system/library/cart/cart

[SooR]

Запускай автотрейс при таких операциях, что-то да вылезет.

Пока что на уме только запросы на внешку, может API платежки/доставки какой

[chukcha]

7 минут назад, SooR сказал:

Пока что на уме только запросы на внешку,

плюс яндекс почта

[Yoda]

Внешних запросов а основных потоках нет. Все расчеты доставок  реализованы выделенными потоками. В свое время очень много этим вопросам было уделено внимания.

Яндекс почты нет. Почта на сервере ходит как пулемет. Айпи спам базах не замечен.

 

1 час назад, nikifalex сказал:

strace?

Не понял. Если честно. 

[Yoda]

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

первое что гугль выдал по теме

http://helpany.ru/strace-examples/

Актуально для ситуаций, когда есть линейная зависимость.

У нас рандомные фризы.

[naprostore]

1 час назад, Yoda сказал:

Вопрос для специалистов.

 

Есть магазин 80 000 товаров.

3500 посетителей в день.

3-5 глубина просмотра.

порядка 20-30к посещений ботов в сутки.

Время генерации страниц без каких-то левых модулей кеширования, "на холодную" в рамках 100-300мс.

Нагрузка на сервере на процессор в пределах допустимого, пик не более 30%.

Расход памяти в пик до 70%.

Медленных запросов в базу - 0.
Поиск реализован на sphinx  - тоже нагрузки создавать не может. 
Потенциальные дыры для ддоса закрыты. Настроено даже ограничение на всплески посещений с одного айпи средствами nginx.

Кеш в redis.

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

При этом регулярно, а особенно в моменты когда покупатели активно добавляют корзины/оформляют заказы, либо менеджеры залогиненные в админке работают с обработкой заказов наблюдаются нелинейные фризы на 7-10 секунд. В ночное время, когда нет активности покуапетелей, подобные зависания практически отсутсвуют. 
Еще раз подчеркну - медленных запросов нет. Тоесть ни к базе ни к серверу, ни к настройкам окружения нет претензий.

 

Что бы вы делали в этой ситуации?

 

 

 

Не пользоваться бесплатными cms, а верстать с "нуля" самому..

[chukcha]

@naprostore беги, @naprostore

[SooR]

@naprostore , там redis уже сверстан самим, написано же. Он только sphinx не верстал, скачал бесплатный.

[Yoda]

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

да не, тут только версткой не обойтись. Всяко еще шаблон нужен хороший платный. нуленый тормозить будет 100%

может вордпресс рядом на сервере стоит и через него ломают.

Самое главное react и vuejs. Ваш этот опыпнкорд устарел и работае только с ябаскрибтом.

[Yoda]

@chukcha, @SooR, @nikifalex, спасибо за обсуждение. На самом деле. Если бы на прошлой неделе мне трижды на разных проектах не пришлось настраивать экстремально длинные сесии, я бы в жизни не догадался куда копать.

Все оказалось до боли просто.

 

В mod-tmp обнаружились полсотни тысяч дескрипторов, которые при gc_divisor 1000 где то раз в 250 посещений проходил garbage collector. Хоть и быстрый VPS, винт общий и виртуализацию никуда не деть, даже скан подобного набора фалов - это ад.

 

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

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

[wbDev]

Ты же сам написал именно про тот момент где сам видишь проблему с сессиями. Хотя это обычное дело, все перелопатишь, а решение на поверхности

[Yoda]

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

Ты же сам написал именно про тот момент где сам видишь проблему с сессиями. Хотя это обычное дело, все перелопатишь, а решение на поверхности

 

Что вы этим хотели сказать? Я не совсем понимаю.

 

[SooR]

@Yoda , а я и забыл про эту пакость. Мне помогал session.gc_probability = 1 или переброс сессий на memcache[d]

[Yoda]

2 часа назад, SooR сказал:

@Yoda , а я и забыл про эту пакость. Мне помогал session.gc_probability = 1 или переброс сессий на memcache[d]

Memcache - зло. Так как очень любит в самый ненужный момент падать, и сбрасывает все данные при перезагрузке демона/сервера. 

Лучше уже в базу.