Еще отключение NCQ немного улучшает ситуацию:
echo 1 > /sys/block/sdb/device/queue_depth
Сразу же скорость синка RAID возрастает до 50 МБ/с (это все равно мало, конечно, но влияние есть).
Решил провести еще раз чистый эксперимент: опять запустил наливку ОС. Когда она налилась, смотрю - RAID синкается со скоростью 4МБ/с (очень медленно), при этом на машине LA=1 и диск /dev/sdb не то что тормозит - он просто ползает:
# hdparm -t /dev/sd?
/dev/sda:
Timing buffered disk reads: 1564 MB in 3.00 seconds = 521.24 MB/sec
/dev/sdb:
Timing buffered disk reads: 4 MB in 4.46 seconds = 919.22 kB/sec
А ведь он только час назад разогнался до 500 МБ/с, после того, как я с него прочитал 50Г! И еще до этого он замечательно жил в роли /dev/sda, а когда его переставили на место sdb - начались вот такие фокусы (причем фокусы старого sdb в этот же момент перенеслись на sda, так что это не корзина виновата, или не только корзина). Ну что же это такое-то. Не пользуйтесь никогда самсунговскими SSD-контроллерами, это просто ужас какой-то.
Так-так... Похоже, скорость sdb восстановилась сама собой. Что я сделал: я запустил
dd if=/dev/sdb of=/dev/null bs=1G count=50
(т.е. прочитал вникуда 50Г данных с начала диска). После этого и hdparm, и dd, и даже cat | pv показывают одинаковую скорость у обоих дисков, в том числе после перезаргузки машины (!).
Может такое быть, что внутри SSD есть какой-то кэш, который этим чтением 50Г заполнился, после чего диск стал работать быстро? Или какой-нибудь фоновой процесс "чистки перышек" внутри самого SSD успокоился, когда я прочитал первые 50Г? (Чтение первых 10Г, кстати, не помогало точно: только когда я прочитал 50Г, диск ожил обратно).
Вот dmesg сразу же после загрузки в recovery mode с эталонного имиджа по сети: pastebin.com/Hdz0KAbu - я ничего подозрительного про диски не заметил там... А что там должно быть, на что обратить внимание?
А как именно вы его используете для отслеживания, можете написать? На каждый запрос дергаете api на стороне piwik? Или скармливаете ему логи? Или piwik напрямую лезет в БД и забирает оттуда данные? Как это работает?
Только тут есть одна проблема — если потом найдется ошибка в запросе (спустя пару недель), то заббикс уже не даст в прошлое пересчитать графики. Плюс он не показывает месячную/квартальную агрегацию (например, число уникальных email-ов в системе за месяц не равно сумме числа уникальных email-ов за 30 дней).
Спасибо. Но все это — средства для учета посетителей по бОльшему счету. Мой вопрос был про другое, про более сложные запросы (типа ответов «сколько процентов из тех, кто закачал фото, оставил больше 1 сообщения?» или «сколько уникальных email-ов сегодня добавилось в базу проекта», или «сколько предложений зафрендиться было отправлено сегодня» в терминах и в примере проекта-соцсети).
Т.е. источник данных — это БД, а не поток событий-логов, как в Google Analytics.
О! Отличная идея! Я уже было обрадовался, что в этом все и дело, но потом посмотрел этот файл — и там прописано
BOOT_DEGRADED=true # modified by installimage
Я также посмотрел в initrd — там то же самое. Может быть, конечно, он не понимает true, а хочет «yes», либо же не воспринимает значок комментария после значения…
Почему-то скриншот поломался — видимо, в Dropbox-е прямые ссылки на картинки все же протухают. Я вставил выше в статье ссылку на скриншот. На нем видно, что дело не в загрузке.
Памяти более чем достаточно. Просто кэш вымывается и вымывается, независимо от того, сколько размер БД — там же идет запись постоянная, а значит, ОС выделяет все новую и новую память для кэша записи. Рано или поздно начинает стираться кэш метаданных (его же сутки не трогали — вот ОС и решает, что можно его под нож).
Дополнение: после запуска find / -type f и просмотра slabtop видим:
2 887 684K ext3_inode_cache
611 768K dentry
В принципе, вполне приемлемо отдать 3.5Г оперативки под этот кэш (разве что мне странно, почему он так много занимает — файлов всего 3 309 564, это больше 1К памяти на файл, хотя хватило бы и 20-30 байт на файл).
Ну и, естественно, первый запуск этой команды отрабатывает минут за 5, а второй — секунды за 4.
Видите, блок в mdstat (и в df, кстати, тоже) — это 4 блока в tune2fs.
Что касается секторов, то как их посчитать, непонятно. Вот что выдает fdisk:
# fdisk -l /dev/sda
Disk /dev/sda: 500.1 GB, 500106780160 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Если перемножить, получим 255*63*60801 = 976768065 — это и есть число секторов? Если это так, то получается 976768065/478142528 = 2 сектора на 1 блок mdstat-а.
Раздел, CD тут ни при чем. Не знаю, может, этот формат называется не ISO, а есть какой-то другой. Главное — чтобы можно было весь раздел (в настоящий момент примонтированный, я отмечу) посекторно преобразовать в файл образа, который бы потом был доступен для подключения через Daemon Tools, к примеру.
В линуксе ведь можно разделы копировать при помощи dd и потом монтировать. Вот нужно что-то подобное, но для Windows.
echo 1 > /sys/block/sdb/device/queue_depth
Сразу же скорость синка RAID возрастает до 50 МБ/с (это все равно мало, конечно, но влияние есть).