LINUX.ORG.RU

Медленная скорость записи на диск CentOS

 , , , ,


0

1

Здравствуйте, Столкнулся с проблемой низкой записи на диск на виртуальной машине. Уже понимаю, что проблема не в битрексе, а в самой системе (CentOS Linux release 7.5.1804 / 3.10.0-862.14.4.el7.x86_64). Вся история:

После обновления centos резко упала скорость записи на диск:

Запись [root@bitrixcrm ~]# sync; dd if=/dev/zero of=tempfile bs=1M count=1024; sync 1073741824 bytes (1.1 GB) copied, 38.4801 s, 27.9 MB/s

Чтение [root@bitrixcrm ~]# dd if=tempfile of=/dev/null bs=1M count=1024 1073741824 bytes (1.1 GB) copied, 0.593443 s, 1.8 GB/s

После поисков по Google изменил параметры в файле /etc/fstab, поставив nobarrier LABEL=bxRoot / ext4 defaults,noatime,nobarrier 1 1 LABEL=bxBoot /boot ext4 defaults,nobarrier 1 2 LABEL=bxSwap swap swap defaults,nobarrier 0 0

Параметры чтения/записи после добавления nobarrier

Чтение: [root@bitrixcrm ~]# sync; dd if=/dev/zero of=tempfile bs=1M count=1024; sync 1073741824 bytes (1.1 GB) copied, 13.6988 s, 78.4 MB/s

Запись: [root@bitrixcrm ~]# dd if=tempfile of=/dev/null bs=1M count=1024 1073741824 bytes (1.1 GB) copied, 0.286018 s, 3.8 GB/s

Развернутый новый битрикс и centos с нуля и залитой старой базой работает отлично, находится на той же тестовой системе рядом с «тормознутой».

Параметры (машина не шибко быстрая): 2012 R2 Hyper V (i3-2120), 16Gb, HDD WD 2Tb

Параметры виртуальной машины: CPU 4, 8192 MB RAM, 80 GB (IDE) Очень хочется понять, в чем же все-таки проблема в системе и почему это произошло именно после обновления centos.

Куда копать? Спасибо.



Последнее исправление: testsoftnet (всего исправлений: 5)

bs=1M count=1024

Ты меряешь скорость чтения из буфера. Чтобы измерить скорость доступа к диску, объем передаваемых данных должен быть раз в 10 больше объема доступной памяти. И делать это лучше с помощью ior, а не dd.
Ну и если там virtio, то 27.9 MB/s это вполне ожидаемо.

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

Понял, спасибо. Просто я рассматриваю эти параметры как некие числа в попугаях. Система собранная с нуля выдает: запись: 1073741824 bytes (1.1 GB) copied, 1.47403 s, 728 MB/s запись: 1073741824 bytes (1.1 GB) copied, 0.358683 s, 3.0 GB/s --- система с ошибкой в десять раз отстает по записи от новой... даже если из буфера.

testsoftnet
() автор топика
Ответ на: комментарий от testsoftnet

С таким подходом ты можешь написать скрипт, который будет делать echo <сколько тебе нравится видеть> и на этом успокоиться. Ни 728 MB/s, ни 3.0 GB/s к скорости записи не имеют никакого отношения. Особенно в сочетании с dd.

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

Не очень хочу привязываться к битриксу т.к. проблема не в нем. Вот цифры теста из битрикса:

Было: База данных MySQL (запись) - 18 количество запросов на запись в секунду

Стало (nobarrier): База данных MySQL (запись) - 561 количество запросов на запись в секунду

ps. mysql крутил как мог, что только не ставил, ничего не помогает. Только когда стал эксперементировать с файловой системой пошел хоть какой-то сдвиг.

testsoftnet
() автор топика

Если уж мерять dd'ой, то вот так:

dd if=/dev/zero of=tempfile bs=1M count=1024 oflag=direct

dd if=tempfile of=/dev/null bs=1M count=1024 iflag=direct

И без всяких sync, так как direct обеспечит запись (в первом случае) и чтение (во втором) без кеширования.

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

спасибо, буду знать. так получается

33 Mb/s запись / 108 Mb/s чтение

и

687 Mb/s запись / 1.1 Gb чтение.

Разница конечно «огонь» пока причину не отрыл :)

testsoftnet
() автор топика
Ответ на: комментарий от testsoftnet

Чтение/запись через dd с direct это максимально приближеный к железу тест. Так что возможно присутствует лишнее кеширование на уровне гипервизора или ещё где-то (которое затрагивает обычное чтение запись). Умная система пытается кешировать запись/чтение, а так как direct запись крайне важна, так как приложение ждёт её окончания, то её все пропускают сразу к диску — и ОС, и возможно даже гипервизор.

chaos_dremel ★★
()
5 мая 2020 г.

про опцию nobarrier

День добрый. Рекомендую почитать про опцию nobarrier

https://habr.com/ru/post/471906/

Если кратко - прирост будет. И риск потери данных тоже будет выше.

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