- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Вчера неожиданно столкнулся со странным явлением. Начиная примерно с 12 часов дня, вдруг начал наростать WAIT IO. Заметил это ближе к вечеру. Стал разбираться. Останавливал всех демонов по очереди, потом перезагрузил сервер. После отключения сайтов нагрузка спала. Что в общем то закономерно. Потом поставил iotop, который не показал ничего подозрительного. Т.е. так и не удалось определить, какой именно демон так активно использует жесткий диск. Примерно в 20:10 WAIT IO резко пропал сам собой.
На сервере работают следующие демоны: nginx, apache, mysql, postgresql, 2 xbt_tracker, deluged, collectd, exim.
Система Debian squeeze
Графики загрузки системы во вложении.
Есть ли у кого-то мысли в чем может быть дело? Потому что у меня уже идеи кончились.
Бывает и не такое, раз всё нормализовалось, значит всё нормализовалось =)
Есть ли у кого-то мысли в чем может быть дело?
Мысли будут после того, как Вы посмотрите кто именно мучал диск утилитой iotop и скажете нам.
Мысли будут после того, как Вы посмотрите кто именно мучал диск утилитой iotop и скажете нам.
В iotop
[kjournald]
apache2
nginx
postgres
mysql
Я же сказал, что по iotop было непонятно кто конкретно там висит. Висели все по-очереди. С опцией -a порядок был примерно такой как я привел выше.
ключевое слово postgresql , думаю autovacuum трудился
ключевое слово postgresql , думаю autovacuum трудился
тоже сначала на него подумал, но догадка не подтвердилась
как проверяли?
В iotop
[kjournald]
apache2
nginx
postgres
mysql
Я же сказал, что по iotop было непонятно кто конкретно там висит. Висели все по-очереди. С опцией -a порядок был примерно такой как я привел выше.
Вы не сказали.
Вывод команды: iotop -b -n3 приведите пожалуйста.
И вообще не имейте привычку гадать. Все можно точно диагностировать. А кофейная гуща не инструмент сурового айтишника.
как проверяли?
его обычно видно в процессах. он появлялся пару раз, но отрабатывал и завершался.
brain-dead добавил 30.09.2010 в 10:09
Вы не сказали.
Вывод команды: iotop -b -n3 приведите пожалуйста.
И вообще не имейте привычку гадать. Все можно точно диагностировать. А кофейная гуща не инструмент сурового айтишника.
К сожалению результат iotop под нагрузкой предоставить не получится. сейчас все в порядке, а те замеры не сохранились.
Скажите что по вашему мнению должен был показать iotop, на что сразу стоило бы обратить внимание?
brain-dead, , reindex тоже небыло? какой раздел активнее всего использовался ? swap / /var /tmp ? смотреть iostat -x 3
Скажите что по вашему мнению должен был показать iotop, на что сразу стоило бы обратить внимание?
Ну вот пример. Смотрите на имена колонок и сразу все станет очевидно: