- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Значит падение не зависит от тех параметров.
По сути верно сказали, при крахе/ребуте самого MySQL в логи пишется инфа
Проверьте uptime.
Может падений не было, а просто все свободные max_connections/max_user_connections заняты, и mysql некуда соединение девать?
Сегодня опять упал мускул.
Из службы админов написали:
В системных журналах сервера баз данных, нет критических ошибок, которые могли бы вызвать его остановку или сбой в работе. Проблема возникшая у Вас была связана с попыткой запуска ещё одного процесса MySQL.
Как такое может быть?
daga, например, встроенный (и не работающий правильно) мониторинг от ispmanager. Там есть галочки специальные -выключите раз на то пошло
Но все равно мало информации. настраивайте munin или хотя бы atop - смотрите историю.
Установлен мунин, панель ДиректАдмин.
daga,как террористы будете по одной картиночке присылать ? огласите ваши требования )
Нет, серьезно. Так дело не сдвинется. Всем вам пишут возможные варианты для размышлений, а не куда именно нажимать.
Ну картинки как картинки. Загрузка ночью подозрительная. Какой-то процесс потреблял 100% одного ядра. Но больше ничего по двум картинкам не сказать. И по трем тоже.
При вашей конфигурации имхо 8 процесов это много, 2 достаточно.
Попробуйте в php отловить, какая ошибка после падения выдается:
Ну и помониторить mysql через "SHOW FULL PROCESSLIST" - возможно какой то запрос надолго зависает.
Попробуйте убрать mysql из мониторинга DA. Возможно это он косячит.
Я тоько один не понимаю почему дебаг падения сюкеля мы делаем через настройки другого совершенно левого демона?
Ошибку 500 выдает вебсервер. Ему до лампочки сюкель.
Для начала нужен дебаг сюкеля (раз он падает), возможно запуск с трассировщиком. А там видно будет. И вообще - падает ли он? По сути никаких вводных для консультации нет.
Ресурсов на оборудовании достаточно? Не шедулер ли его мочит?
Я тоько один не понимаю почему дебаг падения сюкеля мы делаем через настройки другого совершенно левого демона?
Потому что он не падает в том смысле как это привыкли понимать программисты.
Перечитайте внимательно