Andreyka, это все с какой целью было сказано? своп равномерно распределяется по обоим дискам и в случае полного отказа одного из них с большей вероятностью получите произвольную проблему в редкозапускаемой программе.
Полного и удовлетворительного решения описываемой проблемы нет. Остается искать компромиссы и у каждого они свои. Например, полностью отключить своп для снижения вероятности появления mismatch_cnt. Он в основном не нужен на современных серверах.
myhand: Пока все-же больше похоже на проблемы конкретно reiserfs.
Они полностью прекращаются после внеочередной синхронизаций массива. Я давно эту конфигурацию наблюдаю и знаю о чем говорю. В случае рассинхронизации не работает даже reiserfschk, что означает полную фигню на диске. После синхронизации все нормально становится.
myhand, как мы уже выясняли, raid1 читает поочередно с разных блоков. reiserfs ожидает видеть согласованные данные от хранилища нижнего уровня, а не разные. да и любая другая файловая система может быть подвержена тем же проблемам. просто у меня довольно часто перегружался сервер именно с reiserfs. там игнорирование mismatch_cnt гарантированно приводило к проблемам.
Andreyka, как и обычно - меньше шансов на ошибки. если своп не прочитается, то придется убить вытесненную программу потому как ее данных просто нет нигде.
netwind добавил 11.12.2011 в 14:49
myhand: С другой стороны, сценарии "реальных проблем" с mismatch_cnt != 0 на raid1 придумать сложно. Ну, разве вы ручками запишете что-то разное на блины.
нажмите 10 раз reset на приличной нагрузке и наверняка получите расхождение, а с ним проблему на файловой системе. Гораздо более наверняка чем на одиночном винте. По крайней мере reiserfs от подобных фокусов у меня неоднократно портился.
DavyJohnes, все ясно. типичный парсер вконтакта с кучей перекачивающих скриптов. Вряд ли БД узкое место. Попробуйте поставить второй сервер, но в качестве БД для второго скрипты должны использовать первый. С чего вы вообще решили городить репликацию не понятно.
DavyJohnes: Не хватает ширины интернет канала. Возможности увеличить нету.
Ну покажите сайт что-ли. Я сомневаюсь, что средний сайт на среднем сервере способен одним генерируемым html забить 100 мбит. Обычно исчерпываются другие ресурсы.
DavyJohnes, и вместо одного сервера с одной проблемой вы получите две проблемы. Вы действительно исчерпали все ресурсы одного сервера и нет никакой возможности их увеличить?
n1g3r, это же просто уведомление. mismatch_cnt может возникать вследствие высокой загрузки. скорее всего есть другие не связанные с md причины, по которым возникает загрузка и устаканивается. smart проверьте на hdd. или другие ошибки hdd поищите в логах.
Andreyka, это все с какой целью было сказано? своп равномерно распределяется по обоим дискам и в случае полного отказа одного из них с большей вероятностью получите произвольную проблему в редкозапускаемой программе.
Полного и удовлетворительного решения описываемой проблемы нет. Остается искать компромиссы и у каждого они свои. Например, полностью отключить своп для снижения вероятности появления mismatch_cnt. Он в основном не нужен на современных серверах.
Пока все-же больше похоже на проблемы конкретно reiserfs.
Они полностью прекращаются после внеочередной синхронизаций массива. Я давно эту конфигурацию наблюдаю и знаю о чем говорю. В случае рассинхронизации не работает даже reiserfschk, что означает полную фигню на диске. После синхронизации все нормально становится.
Какого рода проблемам, можно подробнее?
например так выглядит
myhand, как мы уже выясняли, raid1 читает поочередно с разных блоков. reiserfs ожидает видеть согласованные данные от хранилища нижнего уровня, а не разные. да и любая другая файловая система может быть подвержена тем же проблемам. просто у меня довольно часто перегружался сервер именно с reiserfs. там игнорирование mismatch_cnt гарантированно приводило к проблемам.
С чего вы вообще решили что БД узкое место? Я уже упоминал что узкое место - интернет канал, за тем и хочу разнести на несколько серверов.
я так не думаю. Но раз вы в первом посте начали планировать репликацию и вынос бд на отдельный сервер, я предположил, что это решили вы.
Какой в этом смысл? Трафик БД тоже большой? Чем меряли?
Andreyka, как и обычно - меньше шансов на ошибки. если своп не прочитается, то придется убить вытесненную программу потому как ее данных просто нет нигде.
netwind добавил 11.12.2011 в 14:49
С другой стороны, сценарии "реальных проблем" с mismatch_cnt != 0 на raid1 придумать сложно. Ну, разве вы ручками запишете что-то разное на блины.
нажмите 10 раз reset на приличной нагрузке и наверняка получите расхождение, а с ним проблему на файловой системе. Гораздо более наверняка чем на одиночном винте. По крайней мере reiserfs от подобных фокусов у меня неоднократно портился.
Какой тип RAID? Если raid1/raid10 - это нормально. В ином случае - повод для беспокойства.
раз уж вы все знаете, как же в таком случае отличить реальную проблему от нормального поведения raid1 ?
Дело там не во включенном swap во время проверки.
я не утверждал, что swap - единственная причина.
DavyJohnes, все ясно. типичный парсер вконтакта с кучей перекачивающих скриптов. Вряд ли БД узкое место. Попробуйте поставить второй сервер, но в качестве БД для второго скрипты должны использовать первый. С чего вы вообще решили городить репликацию не понятно.
Не хватает ширины интернет канала. Возможности увеличить нету.
Ну покажите сайт что-ли. Я сомневаюсь, что средний сайт на среднем сервере способен одним генерируемым html забить 100 мбит. Обычно исчерпываются другие ресурсы.
DavyJohnes, и вместо одного сервера с одной проблемой вы получите две проблемы. Вы действительно исчерпали все ресурсы одного сервера и нет никакой возможности их увеличить?
n1g3r, это же просто уведомление. mismatch_cnt может возникать вследствие высокой загрузки. скорее всего есть другие не связанные с md причины, по которым возникает загрузка и устаканивается. smart проверьте на hdd. или другие ошибки hdd поищите в логах.