- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году 36,9% всех DDoS-атак пришлось на сферу финансов
А 24,9% – на сегмент электронной коммерции
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
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 раза.