Полезно для начала приложение профилировать, может там база вообще не при делах
Базу пихать в докер? Такое себе решение. Контейнеры всё ж больше подходят для stateless штук
+1 Оно-то пихнеся в докер. Но ведь задача докеризованого мускула предоставить легко перемещаемый софт и конфигурацию для масштабирования. Что в нашем случае совершенно беспредметно. Железо на ладан дышит по неизвестной причине.
аномалии типа нормальный цпу-высокий лоад
А что в этом аномального если, например, там hdd тормозит? Или может там диалап-модем
или вообще перевести его на сокет
Когда приложение и база живут на одной железке, то вообще не вижу ни одной причины не использовать сокеты. А выносить базу на отдельную железку - так добавится ещё сеть ко всему. Если уж базу выносить, тогда в приложении кешировать всё то, что ты называешь микрозапросами, или в редисе на хосте с приложением
Пардон, грохнул пост. Изучил скрины. Вангую на базу и нужно софт смотреть. Что-то там не в порядке, с железом там все норм.
Когда приложение и база живут на одной железке, то вообще не вижу ни одной причины не использовать сокеты.
вот это мы как раз не знаем, что там не сокет, конфиг надо смотреть.
А выносить базу на отдельную железку - так добавится ещё сеть ко всему.
Согласен, в данном случае не имеет смысла, железо справляется.
А что в этом аномального если, например, там hdd тормозит?
Типичный кейс. Файловые сессии. Если они не нужны - отключить. Если нужны - использовать мускул или редис.
Я как-то сервер ддосил банальной сессией. несколько тыс открытых файлов - и load avg начинает пиково расти, при этом цпу остается на минимуме
Я как-то сервер ддосил банальной сессией. несколько тыс открытых файлов - и load avg начинает пиково расти до нескольких сотен, при этом цпу остается на минимуме.
Так вот именно, это не аномалия, это вполне себе норма, просто в диск упёрлись
Так вот именно, это не аномалия, это вполне себе норма, просто в диск упёрлись
У мускула тоже есть кеш. Если присутствуют микро запросы - вынудить использовать, памяти хватает. До 1000 в секунду должен пережить.
Но от мусора надо избавляться на уровне приложения.
Гадаем на кофейной гуще...
Некоторые тормоза исправились использованием NVME SAMSUNG EVO потому что обычные SSD INTEL не справлялись.
БАза данных в мускле 50гиг и вторая 40гиг. Вот тормозит из-за одной таблицы в меньшей базе. Админ начал изучать запросы и выяснил, что добавлением индексов можно исправить ситуацию на некоторых страницах сайта, которые я нашел что тупят. Но вот самое непонятное, когда ничего не делаешь, не подкачиваешь никакой инфы, а оно начинает очень тупить. Железо справляется в том числе и накопители. Я думаю что вся проблема с запросами которые кривые, как тут уже сказали. Вот сделать бы какуюто консоль, которая покажет количество времени потраченого на разные запросы...
Некоторые тормоза исправились использованием NVME SAMSUNG EVO потому что обычные SSD INTEL не справлялись.
БАза данных в мускле 50гиг и вторая 40гиг. Вот тормозит из-за одной таблицы в меньшей базе. Админ начал изучать запросы и выяснил, что добавлением индексов можно исправить ситуацию на некоторых страницах сайта, которые я нашел что тупят. Но вот самое непонятное, когда ничего не делаешь, не подкачиваешь никакой инфы, а оно начинает очень тупить. Железо справляется в том числе и накопители. Я думаю что вся проблема с запросами которые кривые, как тут уже сказали. Вот сделать бы какуюто консоль, которая покажет количество времени потраченого на разные запросы...
Говорю же. Без профилирования кода самый простой способ - рекурсивный "show full processlist", собрать статистику и глазами просмотреть. Смотреть в основном на время, которое не соответствует запросу. Имея в наличии сам запрос сможешь сделать ему EXPLAIN и увидишь лажи.
Типовое - на сложных ключах не хватает первого поля. Например ключ по a,b,c а выборка where b,c тогда ключ не используется. И т.п.
Это если преобладают в основном выборки.
Если есть микроапдейты в циклах по полю, на котором есть ключ, однозначно переписать на пакетные апдейты. Фактически даже сотня запросов, переписанная в один, будет выполняться по времени приблизительно столько же, сколько один запрос.
Обычно такие танцы с бубном займут максимум пру часов, ускорение может быть в разы, если не в десятки раз.
Все просто, уже ответили. Кривые руки программистов. Работать с базой не умеют или не хотят. Им тюнинг только подавай Отключи все апдейты если таковы имеются и проверить как работает. Тут нужно кож твоего магазина смотреть и логику работы рисовать что бы понять чем он вообще занимаеться, по другому никак.
Некоторые тормоза исправились использованием NVME SAMSUNG EVO потому что обычные SSD INTEL не справлялись.
БАза данных в мускле 50гиг и вторая 40гиг. Вот тормозит из-за одной таблицы в меньшей базе. Админ начал изучать запросы и выяснил, что добавлением индексов можно исправить ситуацию на некоторых страницах сайта, которые я нашел что тупят. Но вот самое непонятное, когда ничего не делаешь, не подкачиваешь никакой инфы, а оно начинает очень тупить. Железо справляется в том числе и накопители. Я думаю что вся проблема с запросами которые кривые, как тут уже сказали. Вот сделать бы какуюто консоль, которая покажет количество времени потраченого на разные запросы...
попробуйте подключить триал https://newrelic.com/php За время триала успеете пофиксить все проблемы. Там и дешборды будут и анализ запросов..
Не хочешь им просто написать? Имейл внизу. Но тот факт, что сайт падает от обычного трафика, настораживает.
Там похоже какой-то кампус надо /16 блочить
Не хочешь им просто написать? Имейл внизу. Но тот факт, что сайт падает от обычного трафика, настораживает.
да, странно ведет себя. там написано, что они отправляют какието пакеты на какието порты. Выходит что любой может отправить такие же пакеты на сайт и он зависнет....
[ да, странно ведет себя. там написано, что они отправляют какието пакеты на какието порты. Выходит что любой может отправить такие же пакеты на сайт и он зависнет....
Они ясно пишут - собирается статистика о ресурсах инета, анализируются открытые порты. Я так понял в разумных пределах, с их собвственной модерацией. А если отфильтровать лог веб запросов по их подсети, видно что именно делают и как часто? Сложно представить, что вполне публичный ресурс ддосит. Может там вообще ерунда тех запросов, типа пары сотен.
Это значит что сам сайт просто не готов к какому-либо разумному траффику, и лучше сфокусироваться таки на том, где подтормаживает.
А покажи ответ на iptables -L -n , а за одно и netstat -nltp netstat -nlup
[ да, странно ведет себя. там написано, что они отправляют какието пакеты на какието порты. Выходит что любой может отправить такие же пакеты на сайт и он зависнет....
Они ясно пишут - собирается статистика о ресурсах инета, анализируются открытые порты. Я так понял в разумных пределах, с их собвственной модерацией. А если отфильтровать лог веб запросов по их подсети, видно что именно делают и как часто? Сложно представить, что вполне публичный ресурс ддосит. Может там вообще ерунда тех запросов, типа пары сотен.
Это значит что сам сайт просто не готов к какому-либо разумному траффику, и лучше сфокусироваться таки на том, где подтормаживает.
Что показывает full processlist на базе?
Ну тут двоякое мнение. С одной стороны да , оптимизация наше всё. Но если брать то что есть по факту с говнокодом который никто не возьмется переделывать , а если и возьмется то прайс будет не гуманный, то тут вытекает второе мнение. Закрыть все возвожные дыры Fail2Ban + анализ статистики запросов IP. Уже не в первый раз приходится идти по второму варианту. Пока все работает.
Ну тут двоякое мнение. С одной стороны да , оптимизация наше всё. Но если брать то что есть по факту с говнокодом который никто не возьмется переделывать , а если и возьмется то прайс будет не гуманный
Это не мертвый проект с артефактами как я понял. Вроде ж есть активные девы, просто уровнем не вышли. Если найти узкие места, для них же будет левел ап, и остальные дыры закроются достаточно быстро ими же.
Если проект мертвый - то бить точечно, на проблемные участки, выжать максимум из того, что есть. А потом уже бороться "с симптомами" - железо, кеширование, фаервол.
У Пети все работает на сколько мне известно, есть проблемы которые он хочет решить путем железа. Но проблема видать не в железе. Читать код и ловить проблему, тот еще геморой. Но однозначно делать это нужно.
Відповісти
Поперед.
Зміст
Наступ.
Гілками
