1. Какой код ошибки дает материнка? (бывает с индикатором цифровым на самой плате, бывает характерным писком - описание есть в доке к мамке)
2. Работают ли в этих же каналах другие две плашки?
3. Какой там стоит CPU?
Арсен Беспалов: Разные варианты:
1. Последствия креша fs и не очень удачного fsck
2. Чьи то руки
3. если это не /usr/bin/php, а какой то другой файл - то нужный бинарь - /usr/bin/php
Да, Вы увидели здесь слово MariaDB, а не mysql. Сразу оцените что еще есть помимо mysql? - percona, mariadb. Они разные и у всех свои плюсы и все sql-совместимы с mysql, т.е. не требуют переписывания кода.
Изучив какие есть стораджи данных - изучите, как mysql работает с соединениями - по потоку на соединения (+ опции настройки сего), узнайте что процедуры и фукнции mysql/maria/percona использовать неоптимально и почему.
Узнайте о блокировках, транзакция, режимах работы с вводом выводом на диск в mysql.
Узнайте о том, как работает оптимизатор запросов в mysql и что можно узнать из explain.
Потом узнайте о репликации Galera, это поможет Вам балансировать нагрузку на несколько нод.
Обязательно изучите вопрос блокировок и разных storage engine.
Вот такой список тезисов. Проблема в том что централизованно его сложно найти в одном месте.
P.S. используйте persistent connection - чтобы не производить авторизацию при каждом коннекте
К сожалению, там только клики — а вот движения мышью для таких экспериментов зачастую ценее, чем клики.
Клик — результат, а движенье мышью по странице — путь к нему
Скорее мне нужно убедится, что по заданным координатам есть элемент по которому можно кликнуть и произойдет ожидаемое действие. Т.е. я беру этот элемент, делаю window.jQuery(element).click(); и далее assert-ами селениума проверяю что произошло то, что ожидалось.
Ну обычный md в linux прозрачный — можно исключить из raid mirror 1 диск, изменить тип fs с raid на ext3 и легко смонтировать. по сценарию описанному выше можно легко собрать mirror из имеющегося раздела в второго диска.
Вопрос именно в поведении flashcache — все же продукт несколько «стороний» и может не соответствовать другим поведениям md
Да, про рейды так и есть. Бекап есть — realtime реплика диска (drbd).
Вобщем как оказалось — оказался побит один файл — образ диска одной из виртуалок. При обращении к файлу — read/write/stat начинают отваливатся все fs.
Привести сервер в стабильность удалось загрузкой с более младшего ядра — 3.2.0-3-amd64. На этом ядре нормально отработала ситуация с ошибкой доступа inode и падение перестало быть массовым. При обращении к этой иноде (на ядре 3.2.0-3) raid пометил один диск как битый и его мы заменили. Проблема была исчерпана.
Судя по всему в ядре 3.2.0-4 (debian) скрыт какой то баг, от которого сносит крышу у рейдов при обращении к битой части рейда.
Если задача стоит о большом количестве паралельных записей (N виртуалок), то тестить перекидыванием большого файла бесполезно.
Мой Вам совет — разбейте рейд на более мелкие рейды (это поможет распаралелить запись), RAID5 в этом случае будет даже плюсом, т.к. с паралельной записью (в рамках одного рейда) у него всё впорядке.
Лучше проведите более реалистичный тест для Вашей ситуации — установить одну виртуалку, склонируйте её сколько нужно раз, запустите их все и понагружайте. Даже такой тест будет более реалистичен (для Вашей ситуации), чем кидание одного большого файла.
Лучше всего посмотреть нагрузку на железку в момент перекидывания файла. Использование RAM, CPU, количество операация записи и чтения. Из этих данных можно сделать почти однозначные выводы
RAID5 — ru.wikipedia.org/wiki/RAID#RAID_5
проблема в том что каждая операция записи 1го сектора — это посчитать XOR и записать на 2 диска по сектору. (если RAID из 3х дисков), соответственно в 1,5 раза больше нагрузка на диски
