Собственно сабж, есть сервер на котором крутится десятка 2 сайтов разных авторов, и еще большая пачка софта которая конектится к БД через скрипты. Днем когда все пользовали работают с сервером все хорошо, расход оперативы на сервере около 30 процентов, это занятая память всеми процессами линукса. Но как только наступает ночь творится вакханалия, резкий рост потребления оперативы за счет мускула. В течении получаса, мускул на себя берет около 50 процентов оперативы , иногда больше. Проверили лог медленных запросов, там не чего подозрительного нет. Проверили слип запросы - они в течении дня появляются и на расход памяти не как не влияют. Написали даже скрипт делающий kill для слип запросов. Днем все хорошо а ночью хаотично гдето с 22.30 до 5 утра ловинообразно оператива заполняется. Грешили на некоторые крон скрипты, грешили даже на штатный процесс бекапа от ispmanager, передвигали расписание крон скриптов, отключали бекапы. Не как не влияет на хаотичное потребление оперативы. Днем если сделать ребут мускула - потреблеение оперативки так и остается на низком уровне. Поставил на крон задачу, - ребут в 4.30. После перезагрузки через пол часа потребление оперативы опять выросло до прежнего максимального значения. В error журнале мускула только по ночам - too many connections. Не чего более интересного.
Это не проблема, а симптом.
спойлер...
возможно ночью поисковик заглядывает куда-то, где пользователи не бывают. Например, поиск по тегам.
Давным давно, когда я админил шаред хостинги, типовой проблемой были неоптимальные запросы к базе. Одна-две паршивых овцы на 300-400 клиентов на одном сервере могли оттянуть на себя все ресурсы.
Типовое решение - просмотреть show full processlist, сделать запросам explain. Как минимум получится отловить те, которые делают сортировку во временных таблицах или делают поиск в текстовых полях. Иногда будет очевидное решение - индексы, иногда будет сложнее - рефакторинг движка сайта - избавиться от декартового произведения где это не нужно, переписать запросы на left join и добавить лимиты, где этого будет достаточно. Иногда решение слишком очевидно.
А после этого думать что делать дальше если проблема осталась.
Это не проблема, а симптом.
спойлер...
возможно ночью поисковик заглядывает куда-то, где пользователи не бывают. Например, поиск по тегам.
ок, спасибо, будем копать в эту сторону. Только небольшая ремарка, у нас vps сервер на 32 гб оперативы. Т.е. ресурсов не мало, это совсем не общий хостинг в плане производительности.
В error журнале мускула только по ночам - too many connections. Не чего более интересного.
А днем есть too many connections? Может конфиги связанные с коннекшнами плохие? Попробуй юзнуть MySQLTuner и глянуть что он скажет.
В error журнале мускула только по ночам - too many connections. Не чего более интересного.
Кожен коннекшн як раз і жере оперативну пам'ять, навіть як нічого не робить. Шукайте звідки саме їх стільки ночами набігає.
Дещо пальцем в небо, але чи не доступний той ваш мускл всьому інтернету? Боти тоді набігають паролі перебирать, в мускл невдала спроба логіну - це теж коннекшн.
В error журнале мускула только по ночам - too many connections. Не чего более интересного.
Кожен коннекшн як раз і жере оперативну пам'ять, навіть як нічого не робить. Шукайте звідки саме їх стільки ночами набігає.
Дещо пальцем в небо, але чи не доступний той ваш мускл всьому інтернету? Боти тоді набігають паролі перебирать, в мускл невдала спроба логіну - це теж коннекшн.
саме так, ви маете рацію, нажать у нас без зовнішнього доступу до БД ніяк не можна адже частина нашого софту працює напряму з БД без проміжних веб скриптів. І так нас по по ночах різні покидьки трошки бруторсять. Але я не думав що брутфорс може зжерти під 16 гб оперативки (половинку від 32, десь так на око).
В error журнале мускула только по ночам - too many connections. Не чего более интересного.
А днем есть too many connections? Может конфиги связанные с коннекшнами плохие? Попробуй юзнуть MySQLTuner и глянуть что он скажет.
мускултюнер я проверю, раньше он был, но в августе был переезд, так что не помню, пережил ли он переезд. За линки спасибо, почитаю. Кстати, пока причина утечки не найдена, перебиваемся костылями - боремся с симпотомами. Поставил 3 перезагрузки через крон - 5, 5.30, 6 утра. После 3 перезагрузки - утечек оперетивы нет до полуночи минимум. Т.е. до ближайшего полуночного шабаша.
нажать у нас без зовнішнього доступу до БД ніяк не можна адже частина нашого софту працює напряму з БД без проміжних веб скриптів. І так нас по по ночах різні покидьки трошки бруторсять. Але я не думав що брутфорс може зжерти під 16 гб оперативки (половинку від 32, десь так на око).
фаєрволом не можна відкрити тільки на окремі айпі? ну чи хоча б якийсь fail2ban
нажать у нас без зовнішнього доступу до БД ніяк не можна адже частина нашого софту працює напряму з БД без проміжних веб скриптів. І так нас по по ночах різні покидьки трошки бруторсять. Але я не думав що брутфорс може зжерти під 16 гб оперативки (половинку від 32, десь так на око).
фаєрволом не можна відкрити тільки на окремі айпі? ну чи хоча б якийсь fail2ban
нажаль whitelist для підкючення до БД не можна сформувати, бо софт на клієнтських машинах стоїть, там багато різних айпішників. А он скріпт бану за спроби брутфорсити - це варіант.
В error журнале мускула только по ночам - too many connections. Не чего более интересного.
Кожен коннекшн як раз і жере оперативну пам'ять, навіть як нічого не робить. Шукайте звідки саме їх стільки ночами набігає.
Дещо пальцем в небо, але чи не доступний той ваш мускл всьому інтернету? Боти тоді набігають паролі перебирать, в мускл невдала спроба логіну - це теж коннекшн.
саме так, ви маете рацію, нажать у нас без зовнішнього доступу до БД ніяк не можна адже частина нашого софту працює напряму з БД без проміжних веб скриптів. І так нас по по ночах різні покидьки трошки бруторсять. Але я не думав що брутфорс може зжерти під 16 гб оперативки (половинку від 32, десь так на око).
Як ви геть нічим не обмежуєте брутфорс, то він необмежено сжерти і може, йому ж пофіг десять чпроб зробити чи десять мільйонів.
Ідіть гратись в whitelist. Бо інакше це ніяк не припинити. І парольчик рано чи пізно воно ж підбере якийсь.
...
Кожен коннекшн як раз і жере оперативну пам'ять, навіть як нічого не робить. Шукайте звідки саме їх стільки ночами набігає.
Дещо пальцем в небо, але чи не доступний той ваш мускл всьому інтернету? Боти тоді набігають паролі перебирать, в мускл невдала спроба логіну - це теж коннекшн.
саме так, ви маете рацію, нажать у нас без зовнішнього доступу до БД ніяк не можна адже частина нашого софту працює напряму з БД без проміжних веб скриптів. І так нас по по ночах різні покидьки трошки бруторсять. Але я не думав що брутфорс може зжерти під 16 гб оперативки (половинку від 32, десь так на око).
Як ви геть нічим не обмежуєте брутфорс, то він необмежено сжерти і може, йому ж пофіг десять чпроб зробити чи десять мільйонів.
Ідіть гратись в whitelist. Бо інакше це ніяк не припинити. І парольчик рано чи пізно воно ж підбере якийсь.
дякую, зробимо блекліст для любителів брутфорсу.
Если захотят сломать и обнаружат, что фаерволлят, пойдут елочкой.
По хорошему нужно впн с клиентом настраивать. Но до сих пор только предположения в чем именно проблема.
...
саме так, ви маете рацію, нажать у нас без зовнішнього доступу до БД ніяк не можна адже частина нашого софту працює напряму з БД без проміжних веб скриптів. І так нас по по ночах різні покидьки трошки бруторсять. Але я не думав що брутфорс може зжерти під 16 гб оперативки (половинку від 32, десь так на око).
Як ви геть нічим не обмежуєте брутфорс, то він необмежено сжерти і може, йому ж пофіг десять чпроб зробити чи десять мільйонів.
Ідіть гратись в whitelist. Бо інакше це ніяк не припинити. І парольчик рано чи пізно воно ж підбере якийсь.
дякую, зробимо блекліст для любителів брутфорсу.
Блекліст певніше за все вже не допоможе. Там тих ip мільйон. Тільки вайтліст.
+1 до порад VPN та whitelist. Для початку можна зробити широкий на основі "українських" адрес + пододавати туди партнерів, що працюють з хмар. Єдине одразу подумати як автоматизувати ведення цього листу, щоб його міг редагувати не тільки один єдиний адмін. Наприклад, надати можливість першій ланці підтримки додавати ip-адреси просто по дзвінку партнерів.
дякую всім за поради камради На щастя любителі брутфорсу дуже слабенькі. Перевірили логи, там десь до 100 спроб брутфорсу за ніч. Поставили redis та закинули на нього навантаження з самої навантаженої БД. Поки все супер, графшк навантаження оперативи став прямим майже , без стрибків, поки пікове навантаження 34 відсотки на всю ОЗУ. Ще кілька днів помоніторимо, можливо редіс вирішення всіх проблем.
дякую всім за поради камради На щастя любителі брутфорсу дуже слабенькі. Перевірили логи, там десь до 100 спроб брутфорсу за ніч. Поставили redis та закинули на нього навантаження з самої навантаженої БД. Поки все супер, графшк навантаження оперативи став прямим майже , без стрибків, поки пікове навантаження 34 відсотки на всю ОЗУ. Ще кілька днів помоніторимо, можливо редіс вирішення всіх проблем.
Осторожно с ним, восстановление может быть проблемным. У него нет транзакций, а есть флеш интервал с оперативки на диск, по умолчанию секунд 10, кажется. Основная ниша его применения - повторяющееся чтение с возможностью замков, и космический по скорости sorted set, на порядки быстрее аналогичных структур того же Постгреса или Мускула, причем не подвержен недостаткам записи при огромных индексах.
Мускул прекрасно справляется с кешированными запросами. Возможно есть смысл перескочить на Постгрес, он быстрее Мускула в регулярных повторяющихся операциях даже без кеширования.
В некоторых вещах, когда работа с БД - это обычные CRUD запросы через REST, есть смысл поставить над всем кеширующий nginx, решает проблему загрузки на всех уровнях. Нужно смотреть конкретную архетиктуру.
Спасибо всем за советы По итогу плотно перебрали движек одного сайта, несколько недель переделок и тестов, все ок стало. Еще удалось избавится от его лютой БД (15 гб одна БД) и все ок. Теперь за счет бекапов isp поднимается во время бекапа расход оперативы ровно на 15 процентов и так удерживается каждый день. Если не делать бекап с помощью isp, а только консольными командами зиповать сайты и делать mysql дамп то прироста расхода оперативы не наблюдается, висит на уровне 30 процентов.
Відповісти
Поперед.
Зміст
Наступ.
Гілками
