- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Kpd, не обязательно так часто писать логи. Можете задать буфер
production, нельзя останавливать
О, так не бывает.
Попробуйте все же проверить SMART и собрать данные iotop за бОльшие промежутки времени - по 10 сек, 1 минуте. Там ведь интервал по-умолчанию 1 секунда. Может быть, будет более ясно на что обратить внимание - на php или nginx. Тут вам заметили, что суммарная запись из шапки iotop не такая уж высокая.
Как его заставить запускаться всего 1 раз в какой-нибудь понедельник месяца?
Я повторюсь - как в дебиане. Это не такое очевидное выражение. Тот кто это писал, тоже помучился и отразил в комментариях в файле /etc/cron.d/mdadm :
# the month is less than or equal to 7. Thus, only run on the first Sunday of
# each month. crontab(5) sucks, unfortunately, in this regard; therefore this
# hack (see #380425).
57 0 * * 0 root [ -x /usr/share/mdadm/checkarray ] && [ $(date +\%d) -le 7 ] && /usr/share/mdadm/checkarray --cron --all --quiet
Я повторюсь - как в дебиане.
Нет у меня сервера с Дебианом под рукой :)
Первый понедельник месяца получился так:
---------- Добавлено 02.05.2016 в 15:03 ----------
Делать замеры io под рабочим md2_recynd наверное не имеет смысла. Завтра попробую под чистой нагрузкой посмотреть.
Отчет выше - по 10 секунд.
Первый понедельник месяца получился так:
Цитата:
1 1 * * Mon root [ $(date +\%d) -le 7 ] && /usr/sbin/raid-check
думаю так будет лучше:
1 1 1-6 * Mon root /usr/sbin/raid-check
думаю так будет лучше:
1 1 1-6 * Mon root /usr/sbin/raid-check
У меня было прописано
Но recync запустился сегодня
1 1 1-6 * Mon root /usr/sbin/raid-check
я ошибся, не 1-6 а 1-7
Но recync запустился сегодня
потому что день недели отменяет числа
Возможно, тут вот что случилось:
Я похожую картину наблюдал на сыпящихся дисках в софтрейде. Обычные SATA диски при обнаружении ошибки пытаются её исправить - и делают это довольно долго и иногда им это удаётся. Общая производительность падает драматически, но при этом всё работает.
Серверные диски имеют установленной опцию, после которой при возникновении проблемы сразу выдают ошибку и диск вылетает из рейда или что-то ещё происходит восстановительно-исправительное (что может сделать рейд), но производительность в итоге не проседает.
К сожалению, в случае с SATA надпись RAID Edition в данном случае ничего не значит, некоторые диски можно перевести в первый режим, некоторые нет.
При такой низкой скорости я бы попробовал сделать копию на другом сервере или VDS и подать ту же нагрузку и проверить результат.
---------- Добавлено 03.05.2016 в 01:02 ----------
Кстити, включите нужный элеваторный режим оптимизатора - elevator deadline или noop - возможно, это сгладит падение производительности при ресинке. Хотя при такой низкой потребности к скорости записи вряд ли изменения будут заметны.
Частично решил проблему с нагрузкой на диски.
Поставил vm.swappiness=0
(было 10)
recync-а ещё не было, но нагрузка от резервного копирования (по la) упала в 2 раза.