Чрезвычайно низкая скорость диска Centos 6

Настройка выглядит следующим образом:

• HP Proliant DL380 G7
  
• 6 дисков Sata по 3 ТБ (уровень наблюдения) в конфигурации с аппаратным RAID 1 + 0 с контроллером SATA на борту. Модель Seagate SV35
  
• 192 ГБ RAM

VMware ESXi 6.0

• Одна гостевая виртуальная машина с Centos 6.7 (ядро 2.6.32-573)

Хранилище данных состоит из всего оставшегося после установки ESXi дискового пространства (немногим менее 8 ТБ)

• 1 файл VMDK для системного раздела размером 100 ГБ
  
• 1 файл VMDK для раздела данных размером около 7,7 ТБ

В гостевой CentOS системным разделом является LVM ext4.
Раздел данных представляет собой LVM с одним PV, LV и VG ext4

Теперь у меня проблема в том, что скорость передачи данных на диске очень низкая. Попытка скопировать полу-большой файл (10-30 ГБ) из одного места LVM в другое на LVM начинается со скорости передачи около 240 МБ / с, что является скоростью, которую я ожидал бы, но просто через несколько секунд (обычно 30 секунд) он падает до 1-4 МБ / с, а просмотр iotop говорит мне, что запускается процесс с именем flush-253: 2, который, похоже, все замедляет.

Я использовал rsync --progress, чтобы получить лучшее представление о скорости передачи в реальном времени, но я вижу тот же результат с операцией cp.

Когда он, наконец, закончился, я снова попытался выполнить ту же процедуру с тем же файлом в том же месте. Во второй раз указанная скорость передачи rsync остается стабильной на уровне около 240 МБ / с на протяжении всей передачи, но когда rsync указывает, что передача файла завершена, он зависает в этом состоянии примерно столько, сколько потребовалось для завершения процедуры первого копирования. Я вижу, как процесс flush-253: 2 работает так же интенсивно для обеих процедур.

Теперь я знаю, что установка не оптимальна, и я бы предпочел иметь отдельный диск для системы ESXi, но я не думаю, что это должно быть причиной столь крайне низкой скорости передачи.

Я искал информацию о процессе очистки, и, насколько я могу судить, он в основном записывает данные из памяти на настоящие диски, но я не нашел никого, кто сказал бы, что они испытали такой уровень медленной скорости передачи . Система еще не запущена в производство, а ЦП вообще не работает, и у него есть около 100 ГБ свободной памяти для использования при выполнении процедур копирования.

Кто-нибудь знает, что попробовать? Я видел аналогичные результаты в другой системе, которая в основном настроена таким же образом, за исключением совершенно другого (несколько меньшего) оборудования. У меня также есть третья система с CentOS 5 и ext3 на LVM, в которой нет подобных проблем.

РЕДАКТИРОВАТЬ 1: Я понимаю, что сейчас запомнил неправильно, и системный раздел тоже lvm, но все же отдельный том от раздела данных

[root@server /]# mount
/dev/mapper/vg1-lv_root on / type ext4 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw,rootcontext="system_u:object_r:tmpfs_t:s0")
/dev/sda1 on /boot type ext4 (rw)
/dev/mapper/vg1-lv_home on /home type ext4 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
/dev/mapper/vg_8tb-lv_8tb on /datavolume type ext4 (rw,nobarrier)


[root@server /]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg_1-lv_root<br>
                       50G  9.7G   37G  21% /
tmpfs                  91G     0   91G   0% /dev/shm
/dev/sda1             477M   52M  400M  12% /boot
/dev/mapper/vg_1-lv_home
                       45G   52M   43G   1% /home
/dev/mapper/vg_8tb-lv_8tb
                      7.9T  439G  7.1T   6% /datavolume

Обновление 1: Я попытался увеличить dirty_ratio до 90, но никаких улучшений не увидел. Я также пробовал установить его с помощью -o nobarriers, и все тот же результат

Обновление 2: Извините всех, кто пытается помочь мне с путаницей, теперь, когда я сам посмотрел, оборудование на самом деле HP Proliant 380 G7, я не знаю, имеет ли это какое-то значение.

Я также сам посмотрел на конфигурацию рейда, и кажется, что мы используем рейд-контроллер P410, и когда я загружаюсь в систему управления рейдом, он говорит

HP Smart array (I think) P410 "SOMETHING", with 0MB in parenthesis

Я предполагаю, что это может означать, что у нас 0 МБ в кеше записи?

Когда дело доходит до оборудования, я немного не в себе, можете ли вы добавить модуль кеширования записи (?) В этот контроллер рейда, если он еще не существует? Или вам нужен новый контроллер / переход на SAN? Как узнать, есть ли у него кеш записи, но, возможно, разрядился аккумулятор?

Обновление 3: Благодаря вашим предложениям и дальнейшим исследованиям, я сейчас попытаюсь установить файл VIB драйвера интеллектуального массива HP в ESXi и, надеюсь, получу более четкое представление о том, что у меня есть. Я также нашел в системном BIOS возможность включить кеширование дисков, так что у меня может быть последнее средство, если окажется, что у нас нет кеша записи на контроллере.

Обновление 4 (решено): Спасибо всем, кто предлагал решения, и да, оказалось, что на контроллере диска нет модуля кеширования.

Всем, у кого есть подобные проблемы, я установил утилиту hpssacli VIB для ESXi и смог со следующим выводом подтвердить то, что было предложено в ответах.

Cache Board Present: False

Smart Array P410i in Slot 0 (Embedded)
Bus Interface: PCI
Slot: 0
Serial Number: 
Controller Status: OK
Hardware Revision: C
Firmware Version: 6.62
Rebuild Priority: Medium
Surface Scan Delay: 15 secs
Surface Scan Mode: Idle
Parallel Surface Scan Supported: No
Wait for Cache Room: Disabled
Surface Analysis Inconsistency Notification: Disabled
Post Prompt Timeout: 0 secs
Cache Board Present: False
Drive Write Cache: Disabled
Total Cache Size: 0 MB
SATA NCQ Supported: True
Number of Ports: 2 Internal only
Driver Name: HP HPSA
Driver Version: 5.5.0
PCI Address (Domain:Bus:Device.Function): 0000:05:00.0
Host Serial Number: 
Sanitize Erase Supported: False
Primary Boot Volume: logicaldrive 1
Secondary Boot Volume: None