Velocidades de disco extremadamente lentas Centos 6

El progtwig de installation se ve así:

  • HP Proliant DL380 G7
  • 6 discos SATA de 3 TB (nivel de vigilancia) configurados con hardware RAID 1 + 0 con el controller SATA a bordo. El model es Seagate SV35
  • 192 GB de RAM

VMware ESXi 6.0

  • Un invitado de VM que ejecuta Centos 6.7 (Kernel 2.6.32-573)

Datastore se compone de todo el espacio en disco restante después de la installation de ESXi (poco less de 8tb)

  • 1 file VMDK para la partición del sistema a 100 GB
  • 1 file VMDK para la partición de datos en torno a 7.7TB

En el CentOS invitado, la partición del sistema es LVM ext4
La partición de datos es un LVM con un solo PV, LV y VG ext4

Ahora el problema que tengo es que las velocidades de transferencia de datos en el disco es extremadamente lento. Tratar de copyr un file semi-grande (10-30 GB) de un lugar en el LVM a otro en el LVM comienza con una velocidad de transferencia de alnetworkingedor de 240 MB / s, que es la velocidad que yo esperaría que tenga, pero sólo después de unos segundos (30ish por lo general) se networkinguce a 1-4 MB / s, y viendo iotop me dice que un process comienza a ejecutarse llamado flush-253: 2 que parecen ralentizar todo.

He estado usando rsync –progress para get una mejor image de las velocidades de transferencia en time real, pero estoy viendo el mismo resultado con una operación cp.

Cuando finalmente termina, he intentado realizar el mismo procedimiento otra vez, con el mismo file a la misma localización. La segunda vez que la velocidad de transferencia indicada de rsync se mantiene constante en alnetworkingedor de 240MB / s a ​​lo largo de toda la transferencia, pero cuando rsync indicó que la transferencia de files se ha completado se cuelga en ese estado durante el time necesario para completar el primer procedimiento de copy. Puedo ver el process flush-253: 2 trabajando tan duro para ambos procedimientos.

Ahora sé que la configuration no es óptima, y ​​yo hubiera preferido tener un disco separado para el sistema ESXi, pero no me siento como que debería ser la causa de este extrema velocidades de transferencia lentas.

He buscado información sobre el process de descarga, y por lo que puedo decir, básicamente escribe datos de la memory en los discos reales, pero no he encontrado a nadie diciendo que han experimentado este nivel de velocidades de transferencia lentas . El sistema todavía no está en producción y la CPU casi no funciona, y tiene alnetworkingedor de 100 GB de memory libre para usar cuando se ejecutan los procedimientos de copy.

¿Alguien tiene alguna idea sobre qué probar? He visto resultados similares en un sistema diferente que básicamente se configura de la misma manera, excepto en hardware completamente diferente (algo menor). También tengo un tercer sistema que ejecuta CentOS 5 y ext3 en LVM, que no tiene ningún problema como este.

EDIT 1: Me doy count de que ahora había recordado incorrectamente, y la partición del sistema es también lvm, pero sigue siendo un volumen separado de la partición de datos

[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 

Actualización 1: he intentado boost la dirty_ratio todo el path hasta 90, y todavía no veía mejoras. También intenté montarlo con -o no barreras, y todavía el mismo resultado

Actualización 2: Lo siento a todos los que están tratando de ayudarme sobre la confusión, ahora que he tenido un aspecto yo mismo, el hardware es en realidad un HP Proliant 380 G7, no sé si eso hace alguna diferencia.

También he echado un vistazo a la configuration de raid, y parece que estamos usando un controller de raid P410, y cuando estoy iniciando en la gestión de raid, dice

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

Supongo que eso podría significar que tenemos 0 MB en caching de escritura?

Estoy un poco fuera de mi profundidad aquí cuando se trata de hardware, puede agregar un module de memory caching de escritura (?) A este controller raid si uno ya no existe? ¿O necesita un nuevo controller / mover a una SAN? ¿Cómo puedo saber si tiene un caching de escritura, pero tal vez la batería está muerta?

Actualización 3: gracias a sus sugerencias y más investigación, ahora voy a intentar e instalar el file de file inteligente de la matriz inteligente HP en el ESXi, y espero get una image más clara de lo que tengo. También encontré la opción en el BIOS del sistema para habilitar la memory caching de la unidad, por lo que podría tener un último recurso en caso de que resulta que no tenemos escritura caching en el controller.

Actualización 4 (resuelto): Gracias a todos los que sugirieron soluciones, y sí resultó que no había module de caching presente en el controller de disco.

Para cualquier persona que tenga problemas similares, instalé la utilidad de hpssacli VIB para ESXi, y podría con la salida siguiente confirmar lo que había sido sugerido en las respuestas.

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 

No parece que tenga ningún caching de escritura.

Confirme la generación y el model de su server. Si no tiene un module de caching de escritura respaldado por Flash (FBWC) en el controller al que están conectados sus discos, el performance de VMware sufrirá.

La otra cuestión aquí es LVM y algunos de los valores por defecto que apareció en RHEL6 hace unos años. Usted querrá probar esto con la inhabilitación de barreras de escritura. LVM puede ser un problema porque conduce a la gente a evitar la partición de sus volúmenes … Y eso afecta la capacidad de herramientas como tuned-adm para hacer su trabajo.

Pedí la salida del mount . ¿Puede por favor publicarlo?

Intente montar sus volúmenes con la bandera no barrier . Las barreras de escritura son el valor pnetworkingeterminado para EL6 en ext4, por lo que es el problema más grande que se está ejecutando.

Parece que su controller RAID no tiene caching. El principal problema es que la tarjeta RAID de hardware tiende a deshabilitar, de forma pnetworkingeterminada, la memory caching de DRAM privada del disco.

En pocas palabras, esto significa que cuando, después de unos segundos (~ 30, para ser precisos) el pagecache sucio se descarga en el disco, un montón de request de E / S random comienza a martillar su disco lento (lenta), matando el performance.

Vuelva a habilitar la caching DRAM privada de su disco (es una opción de controller RAID, a menudo) y el performance debe upload. Para una escritura aún más rápida, puede desactivar las barreras de escritura (con la opción de installation nobarrier ) pero desafortunadamente, sin una caching de BBU, apagarlas afectará la confiabilidad de los datos en caso de fallo del sistema o apagón.

EDIT: dar una mirada aquí para más información.

Parece un duplicado de esto:

Flush-0: n processs que causan cuello de botella masivo

De hecho, usted debe comprobar el dirty_ratio, cómo va es que la primera escribe va en la RAM por lo que tiene una tasa de IO muy rápido en el inicio. Más tarde, cuando la RAM se llena hasta dirty_ratio, el kernel comienza a llenar el disco.

Algunas preguntas:

  • ¿Tiene todos los controlleres instalados correctamente para su DL 360?
  • ¿De qué generación es este server? ¿Es un server G9?
  • ¿Qué tipo de controller es? Smart Array XXXXX? ¿Ha instalado un module de caching para el controller?
  • ¿Utiliza discos duros originales de HP?

y dos notas personales: – No creo que realmente llegue a 240 MB / s con 6 unidades SATA lentas con 7,2K y un RAID 10.

  • Lo que realmente no entiendo: ¿Por qué comprar un DL360 con 192 GB de RAM (no es barato si es ECC Ram) y luego poner allí algunos baratos, stupide y SATA HDD lento está ahí? ¿Por qué no obtuvo un 380 y poner allí algunos más rápidos SAS 2,5 "HDDs allí … Como un ejemplo: creo que podría tener mucho más velocidad con 10 900GB SAS 10k unidades o 15 unidades de 600k … Creo que sería mucho más rápido, incluso si se utiliza un RAID 5 … ok, tal vez no tenía ninguna opción en esto, pero creo que la configuration del server no es muy agradable … Sé que esta configuration no puede explicar su cp muy lento, pero de todos modos …