- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Всем привет!
Классика жанра, я просыпаюсь, открываю браузер и вижу что-то типа такого – нет доступа к базе данных, ну думаю опять взломали или еще какая фигня приключилась.
Уже достаточно давно такого не было и все работало как обычно достаточно долго без таких сбоев, короче вспомнил как заходить на сервер, посмотрел статус mysqld, там что-то было написано из разряда что она работает, но не работает, перезапустил её и все ОК, все заработало, хз что там было.
Что это могло быть:
Взлом / DDOS атака / глюк
Нужно ли менять все пароли, связанные с базой данных?
Глянул мельком логи, но там ничего интересного, куча обычных повседневных варнингов, даже нет толком упоминания почему она остановилась, далее только запись о старте, после моего ручного рестарта.
После перезагрузки все работает в штатном режиме, куча памяти более 50% еще свободна, процессор практически не загружен что-то там среднее 0.20, все работает как обычно.
Слышал байку что такое может быть из-за тяжелых запросов к базе данных которые могут делать некачественные стремные плагины или я сам. И действительно недавно добавил еще дополнительной выборки из базы данных с помощью плагина, кажется, что запрос там тяжеловат видно, как нагрузка на страницу стала больше, но дело в том, что по сути у меня отдаются готовые страницы из закэшированных страниц, и единственный кто делает этот запрос сам плагин кэширования, но и я бы не сказал, что там прям супертяжелая выборка, но до этого нововведения вроде падений базы данных не было, хз может это и с этим связанно.
На данный момент – памяти море, проц. не загружен, все работает как работало.
Напишите мне Димон это был глюк, забей! :-)
Заранее всем спасибо за ответы!У меня такое было - нехватка места на диске.
df –h показывает что место еще вроде как есть, доступно около 20 гигов, используется написано 60%, значит типа 40% свободно, должно хватать мне кажется так.
df –hi если говорить про inode вроде показывает что занято только 12%, то есть 88% еще свободны, ну это вообще очень много свободно.
Ну не знаю вроде запасы места есть.df –h показывает что место еще вроде как есть, доступно около 20 гигов, используется написано 60%, значит типа 40% свободно, должно хватать мне кажется так.
чтобы не гадать, надо ставить какие-нибудь скрипты-уведомлялки как простое решение или например какой-нибудь заббикс поднимать. У меня было такое что за несколько месяцев только файлов сессий на 100Гб накапливалось
А могло ли бы быть такое, в теории конечно, произошел какой-то всплеск перерасхода памяти и OOMKiller завершил процесс mysqld, сайтик не смог подключится к базе данных, я её перезапустил и все заработало.
Можно ли вообще где-то посмотреть кто остановил или завершил процесс в системе.вряд ли вам кто-то что-то подскажет без логов, конфигов, версий ПО, размера базы, доступной памяти, может быть всё что угодно, вплоть до уязвимости в самом mysql
если хотите знать, не оом ли киллер убил процесс, то скорее всего эта информация находится в логе /var/log/messages
также можете погуглить на тему использования journalctl
вряд ли вам кто-то что-то подскажет без логов, конфигов, версий ПО, размера базы, доступной памяти, может быть всё что угодно, вплоть до уязвимости в самом mysql
если хотите знать, не оом ли киллер убил процесс, то скорее всего эта информация находится в логе /var/log/messages
также можете погуглить на тему использования journalctl
Спасибо, нашел такую строчку в /var/log/messages:
May 1 20:12:53 mysitedomen kernel: [3097011.187145] Out of memory in UB 12537891: OOM killed process 1051 (mysqld) score 0 vm:5058865kB, rss:2238825kB, swap:0kB
Я так понимаю это значит, что система сама убила этот процесс из-за нехватки памяти.
Значит это не взлом сайта какой-то, я надеюсь.
Осталось понять почему произошло переполнение памяти, и из-за чего она понадобилась вдруг вся mysqld в моменте?Осталось понять почему произошло переполнение памяти, и из-за чего она понадобилась вдруг вся mysqld в моменте?
А кто вам сказал, то она потребовалась mysqld ? Просто mysqld самый жирный, его и раскулачили.
А кто вам сказал, то она потребовалась mysqld ? Просто mysqld самый жирный, его и раскулачили.
Тогда это все немного усложняет, да никто не сказал, я сам себе придумываю объяснение т.к. связано с базой данных, я подумал, что в какой-то момент ей понадобилось много памяти и из-за нехватки памяти процесс убила система что логи подтверждают, ну я так себе это представляю.
Но если переполнение памяти было связанно не с mysqld и если это какой-то другой процесс, то тогда я даже не знаю, я бы спросил – как посмотреть какой процесс забрал всю память и заставил систему убить mysqld из-за этого, но думаю, что такого ответа нет.
Ладно пусть поработает пока, а там посмотрим, если еще раз зависнет, что-то буду думать. Пока вроде работает, всю память не съедает.
Тогда фиг его знает, что делать, если это не mysqld, то что сожрало всю память…Доставать калькулятор и раздавать всем по потребностям и по лимитам.
VDS это не виртуальный хостинг.