LINUX.ORG.RU
решено ФорумAdmin

Низкая скорость чтения/запись

 ,


1

4

Приветствую!

Есть сервер DELL PowerEdge R720
На нем есть апаратный raid контроллер (PERC H710 Mini). Создан рейд-1 из 2x300G INTEL SSDSC2BB30
Почему такая низкая скорость записи на диск?

 
# mount
/dev/sda3 on /home type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)


# hdparm -Tt /dev/sda
/dev/sda:
 Timing cached reads:   644 MB in  2.00 seconds = 321.90 MB/sec
 Timing buffered disk reads: 246 MB in  3.01 seconds =  81.82 MB/sec

# dd count=1000 bs=1M if=/dev/zero of=/home/test.tmp
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 17.8669 s, 58.7 MB/s

//Возможно чтение было с кэша, незнаю как правильно кэш очистить
# dd bs=1M if=/home/test.tmp of=/dev/null
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 4.06023 s, 258 MB/s 
★★★★

А не пробовал ssd-хи воткнуть в обычный sata(а не в raid контроллер), например на обычном компе или ноуте.. Мож у тебя диски (или один из дисков) не пашет?

Acceptor ★★ ()

Еще одна проблема вылезла
Перекодирование mp3 через lame
Ядро занято на 100% а кодирует очень медленно, хотя раньше было раз в 5 быстрей

Linux x 3.2.0-4-amd64 #1 SMP Debian 3.2.63-2+deb7u2 x86_64 GNU/Linux

kiotoze ★★★★ ()
Ответ на: комментарий от CHIPOK
# sync && echo 3 > /proc/sys/vm/drop_caches
# dd count=1000 bs=1M if=/dev/zero of=/home/test.tmp
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 24.0522 s, 43.6 MB/s

# sync && echo 3 > /proc/sys/vm/drop_caches
# dd count=1000 bs=1M of=/dev/zero if=/home/test.tmp
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 9.98261 s, 105 MB/s
kiotoze ★★★★ ()
Ответ на: комментарий от kiotoze

ну вот твоя скорость чтене/запись без кеша. А скорость конечно печаль, мож dmesg че полезного пишет, смотрел?

CHIPOK ★★★ ()

Недавно вроде была статья на швабре по этому поводу. Если в двух словах, обнови ядро.

itn ★★ ()
Ответ на: комментарий от CHIPOK

Похоже проблема нашлась в dmesg
Когда сервер перезагрузился я туда смотрел, но

Package power limit notification (total events = 4473949)
небыло. Наверное дал больше нагрузки на проц и тогда появились эти сообщения.
Сейчас попробую эти советы
Еще насторожило
[    0.633815] ------------[ cut here ]------------
[    0.634855] WARNING: at /build/linux-pTuYXd/linux-3.2.63/drivers/iommu/intr_remapping.c:558 enable_intr_remapping+0x71/0x266()
[    0.635976] Hardware name: PowerEdge R720
[    0.636897] Your BIOS is broken and requested that x2apic be disabled
[    0.636935] This will leave your machine vulnerable to irq-injection attacks
[    0.636937] Use 'intremap=no_x2apic_optout' to override BIOS request
[    0.639777] Modules linked in:
[    0.641421] Pid: 1, comm: swapper/0 Not tainted 3.2.0-4-amd64 #1 Debian 3.2.63-2+deb7u2

kiotoze ★★★★ ()
Последнее исправление: kiotoze (всего исправлений: 1)
Ответ на: комментарий от kiotoze

Для теста из бэкпортов поставь, или live-убунту запусти. Я точно помню что у 3.2 были проблемы с ссд.

itn ★★ ()
Ответ на: комментарий от kiotoze

дебиан как всегда стабилен, ничего не меняется

anonymous ()

На данный момент ситуация следующая:
после установки clearcpuid=229 ошибки перестали залетять в dmesg, но скорость не выросла

Самое главное, что вчера все работало и на сервере ничего не менялось и lame работал быстро. А сегодня lame стал работать намного медленней и поэтому я пошел искать в чем причина и так нашел проблему со скоростью. Потом решил обновить ядро и вероятно тогда вылезла проблема с performance limit. Я веду к тому, что возможно я не туда смотрю и ошибка совсем в чем-то другом? Но как найти причину?

kiotoze ★★★★ ()
Ответ на: комментарий от kiotoze

Some magic has been detected

Начал гонять всякие тесты, sysbench, etc
И тут попробовал еще раз dd запустить

# dd count=1000 bs=1M if=/dev/zero of=/home/test.tmp
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 3.21616 s, 326 MB/s
Ненавижу когда так( Скорее всего потом опять вылезет и как обычно в самый не подходящий момент

kiotoze ★★★★ ()
Ответ на: Some magic has been detected от kiotoze

Вообще dd это конечно тухлый создатель нагрузки. Никакого параллелизма, все операции последовательны (как во времени, так и в LBA). Из умных железок весь их потенциал вытянуть не может. Для реальных тестов надо использовать fio.

Ну и кешей и тебя в системе получается много: кеш в RAM сервера, кеш в RAM контроллера PERC H710 mini (вроде 512 MB), кеш в RAM SSD (вроде 1 GB). echo 3> drop_caches очищает только кеш в RAM сервера. Так что твой 1 GB workload умещается в RAM одного диска.

Сделай тест с помощью fio используя движок asyncio на случайную запись блоками по 8 KB объёмом в 10 GB по 100 GB диапазону LBA с параллельностью 4..8..16..32. Тогда все кеши точно насытятся, и ты получишь представление о том, как это будет работать при нагрузке типа OLTP базы данных.

iliyap ★★★★★ ()

Попробуй выключить кеширование записи, если оно включено.

iron ★★★★★ ()
Ответ на: комментарий от iliyap

dd это конечно тухлый создатель нагрузки

for _ in {1..100500};do dd if=/dev/zero of=/tmp/test bs=4M &;done

anonymous ()
Ответ на: комментарий от erzent

Возможно)

На данный момент проблема решена, как проявит себя в следующий раз - будем искать причины

kiotoze ★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.