- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году 36,9% всех DDoS-атак пришлось на сферу финансов
А 24,9% – на сегмент электронной коммерции
Оксана Мамчуева
Каждую неделю вываливается такое сообщение-ошибка. Количество не синхронизированных блоков всегда разное. Примерно 8-10к. Что много. Панелька isp. Такое чувство, что ошибка вылазит после бекапа. Ручками делаю синхронизацию - все ок. С блинами проблем нету. Но каждую неделю вручную делать синхронизацию - тоже не выход. У кого были или есть такие проблемы и как их решали? Центос 5 стоит.
n1g3r, в редхате считают, что это нормально.
https://bugzilla.redhat.com/show_bug.cgi?id=547128
https://bugzilla.redhat.com/show_bug.cgi?id=566828
в fedora даже изменили этот скрипт чтоб не ругался.
swap у вас есть? попробуйте выключить. может быть бекап и проверка массива происходят вместе и в этот момент swap активно используется что и приводит к разнице.
я редко наблюдаю такие ошибки и по-моему они возникают после внезапных перезагрузок, что объяснимо.
netwind
Спасибо. Да, swap есть. Попробую. Только это не нормально, так как когда это значение большое, скажем больше 1к, то тогда начинает все тормозить и загрузка сервера идет на полную, сайты грузятся через раз с 502 ошибкой nginx, мускуль тоже покашливает, пока вручную не сделаешь синхронизацию блоков.
n1g3r, это же просто уведомление. mismatch_cnt может возникать вследствие высокой загрузки. скорее всего есть другие не связанные с md причины, по которым возникает загрузка и устаканивается. smart проверьте на hdd. или другие ошибки hdd поищите в логах.
smart проверял, лонг, проблем не нашел.
Каждую неделю вываливается такое сообщение-ошибка. Количество не синхронизированных блоков всегда разное.
Какой тип RAID? Если raid1/raid10 - это нормально. В ином случае - повод для беспокойства.
swap у вас есть? попробуйте выключить. может быть бекап и проверка массива происходят вместе и в этот момент swap активно используется что и приводит к разнице.
Дело там не во включенном swap во время проверки. Дело во включенном swap вообще. Хотя, к подобной "рассинхронизации" приводят еще несколько сценариев.
http://bugs.debian.org/518834
С подачи дебиана все давно поправили в документации (man 4 md, раздел SCRUBBING AND MISMATCHES).
smart проверял, лонг, проблем не нашел.
Смарт должен запускаться регулярно. Для этого есть smartd.
Какой тип RAID? Если raid1/raid10 - это нормально. В ином случае - повод для беспокойства.
раз уж вы все знаете, как же в таком случае отличить реальную проблему от нормального поведения raid1 ?
Дело там не во включенном swap во время проверки.
я не утверждал, что swap - единственная причина.
Кстати а какой смысл хранить свап на рейде?
как же в таком случае отличить реальную проблему от нормального поведения raid1 ?
Боюсь, что никак. Речь лишь о том, что для некоторых типов рейда - эти показатели фактически бесполезны.
С другой стороны, сценарии "реальных проблем" с mismatch_cnt != 0 на raid1 придумать сложно. Ну, разве вы ручками запишете что-то разное на блины.
я не утверждал, что swap - единственная причина
Тем не менее, вы предложили конкретное объяснение. Неверное в принципе.
Кстати а какой смысл хранить свап на рейде?
Разбивка по-умолчанию.
Andreyka, как и обычно - меньше шансов на ошибки. если своп не прочитается, то придется убить вытесненную программу потому как ее данных просто нет нигде.
netwind добавил 11.12.2011 в 14:49
С другой стороны, сценарии "реальных проблем" с mismatch_cnt != 0 на raid1 придумать сложно. Ну, разве вы ручками запишете что-то разное на блины.
нажмите 10 раз reset на приличной нагрузке и наверняка получите расхождение, а с ним проблему на файловой системе. Гораздо более наверняка чем на одиночном винте. По крайней мере reiserfs от подобных фокусов у меня неоднократно портился.
нажмите 10 раз reset на приличной нагрузке и наверняка получите расхождение, а с ним проблему на файловой системе.
Ну, в этом случае - вы как раз и "ручками запишете что-то разное на блины".
Вот только вряд-ли это приведет к реальным проблемам (потерю части "кривозаписанных" данных за таковую не считаем). Таки журналируемые файловые системы используют обычно. Странно, что reiserfs у вас портился.
Теоретически, нормально исправить проблему можно, но разработчик очень подробно объяснил (см. баг в дебиане) почему это приведет к существенному снижению производительности (или переусложнению). Короче, более разумного решения чем "забить на это для raid1/raid10" - нету и не предвидится.