Micro instancia de Amazon EC2 gran cantidad de requestes de IO

Estoy tratando de entender por qué tengo una gran cantidad de requestes EBS de EBS en mi microinstancia Amazon EC2. Lancé la instancia hace aproximadamente 6 días y acumulé más de 4 millones de requestes de IO hasta el momento. La instancia viene precargada con una stack LAMP (Virtualmin, PHP, Apache, MySQL). Instalé un sitio de WordPress y solo lo cargué en un browser varias veces para hacer algunas testings.

¿Alguien puede guiarme en cómo determinar qué está generando todas estas requestes de IO posiblemente usando iotop u otra utilidad de Linux?

También agregaría las siguientes 3 herramientas a la mezcla. Suponiendo que los tiene instalados, de lo contrario debería poder instalarlos a través de cualquier repository que se proporcione a su instancia de ec2.

Es probable que la alta carga sea causada por el disco o la E / S de networking, así que me centraría en esas 2 áreas para comenzar.

nethogs

La creación de networkinges sería mi primera sospecha, para diagnosticar eso más adelante, utilizaría nethogs para ver qué processs lo están causando.

Ejemplo

Determine su interfaz de networking, para que pueda decirle a los nethogs cuál debe mirar.

 $ ip link show up | awk '/UP/ {print $2}' lo: em1: wlp3s0: virbr0: 

En mi caso, voy a ver mi dispositivo inalámbrico, wlp3s0 .

 $ sudo nethogs wlp3s0 NetHogs version 0.8.0 PID USER PROGRAM DEV SENT RECEIVED 2151 saml /opt/google/chrome/chrome wlp3s0 2.117 2.715 KB/sec 3569 saml ..4/thunderbird/thunderbird wlp3s0 0.441 1.496 KB/sec 3144 saml ..aml/.dropbox-dist/dropbox wlp3s0 0.081 0.061 KB/sec 3383 saml pidgin wlp3s0 0.026 0.056 KB/sec 4025 saml ssh wlp3s0 0.000 0.000 KB/sec ? root unknown TCP 0.000 0.000 KB/sec TOTAL 2.665 4.327 KB/sec 

Mirando la salida, podemos ver que chrome está usando la mayor parte de mi ancho de banda.

iftop

Puede ver si el tráfico proviene de un set específico de sitios usando iftop .

  195kb 391kb 586kb 781kb 977kb └───────────────┴───────────────┴───────────────┴───────────────┴─────────────── greeneggs.bubba.net => stackoverflow.com 4.68kb 10.2kb 8.24kb <= 33.5kb 14.7kb 21.4kb greeneggs.bubba.net => ord08s12-in-f8.1e100.net 0b 3.90kb 3.99kb <= 0b 3.61kb 3.72kb greeneggs.bubba.net => ord08s10-in-f16.1e100.net 5.05kb 4.10kb 5.83kb <= 2.43kb 2.39kb 2.79kb greeneggs.bubba.net => stackoverflow.com 1.32kb 3.34kb 4.73kb <= 1.30kb 1.60kb 2.30kb greeneggs.bubba.net => cpe-67-253-170-83.rochest 0b 2.19kb 760b <= 0b 2.60kb 862b greeneggs.bubba.net => pop1.biz.mail.vip.ne1.yah 5.87kb 1.17kb 301b <= 17.4kb 3.47kb 889b greeneggs.bubba.net => 190.93.247.58 480b 2.04kb 2.66kb <= 0b 1.34kb 1.80kb greeneggs.bubba.net => ig-in-f95.1e100.net 448b 1.02kb 1.27kb <= 240b 437b 534b greeneggs.bubba.net => ord08s12-in-f2.1e100.net 896b 346b 218b <= 480b 221b 124b ──────────────────────────────────────────────────────────────────────────────── TX: cum: 652kB peak: 85.2kb rates: 20.6kb 29.3kb 30.1kb RX: 883kB 161kb 57.9kb 31.4kb 40.6kb TOTAL: 1.50MB 241kb 78.5kb 60.7kb 70.7kb 

fatrace

Puede usar la herramienta fatrace para ver qué processs están causando accesos al HDD.

 $ sudo fatrace pickup(4910): O /var/spool/postfix/maildrop pickup(4910): C /var/spool/postfix/maildrop sshd(4927): CO /etc/group sshd(4927): CO /etc/passwd sshd(4927): RCO /var/log/lastlog sshd(4927): CWO /var/log/wtmp sshd(4927): CWO /var/log/lastlog sshd(6808): RO /bin/dash sshd(6808): RO /lib/x86_64-linux-gnu/ld-2.15.so sh(6808): R /lib/x86_64-linux-gnu/ld-2.15.so sh(6808): O /etc/ld.so.cache sh(6808): O /lib/x86_64-linux-gnu/libc-2.15.so 

¿Qué más?

Echaré un vistazo a este Q & A de Unix & Linux que respondí hace un time para más herramientas para probar. Se titula: Determinación del file específico responsable de altas E / S.

Preguntas de seguimiento de los comentarios

Q1: ¿El ancho de banda mostrado por los nethogs count contra las requestes de IO en AWS? Pensé que caería bajo 'transferencia de datos' que es una categoría separada. En iotop, el mayor porcentaje de uso fue root y un command llamado 'kswapd0'. mysqld tenía el mayor uso de escritura en disco y httpd tenía la mayor cantidad de lecturas de disco

No tengo idea de cómo Amazon rastrea esto realmente. Estos valores son desde la perspectiva del host VM para que no se correlacionen remotamente con lo que Amazon está rastreando el uso de su máquina virtual desde su perspectiva.

Por cierto, este kswapd0 es probablemente la fuente de sus altas requestes de IO. Esto es complicado porque, lo más probable es que su VM no tenga suficiente RAM para satisfacer el tamaño / uso de las aplicaciones que está ejecutando en la VM. Entonces, para tratar de satisfacer la necesidad que su sistema está recurriendo al uso de swap.

Puede confirmar esto un poco más a través del command free .

Ejemplo

 $ free -ht total used free shanetworking buffers cached Mem: 7.6G 5.5G 2.1G 0B 446M 2.5G -/+ buffers/cache: 2.6G 5.0G Swap: 7.6G 40K 7.6G Total: 15G 5.5G 9.7G 

Esto le muestra la cantidad de RAM y swap que utiliza su sistema.

Q2: Ah y una pregunta de seguimiento. ¿Cómo se relacionan el MB o KB del disco de lectura / escritura en iOTOP con el número de requestes de IO? Por ejemplo, si mysqld escribió 20 M en el disco, ¿hay alguna manera fácil de saber cuántas requestes de IO generaron?

En realidad, no conozco ninguna correlación con respecto al número de lecturas / escrituras IO y la cantidad agregada de datos leídos / escritos en el disco.

Dado que está utilizando AWS, sus lecturas / grabaciones de disco reales pueden no ser ni siquiera en un disco local, sino en almacenamiento a través de la networking (SoE, también conocido como SCSI sobre Ethernet, por ejemplo).

Su máquina virtual sería completamente ajena a esto, ya que la configuration de SoE probablemente se haría en el nivel de host y luego se expondría como discos a cualquier máquina virtual que se ejecute en el host.

Referencias

  • fatrace: informa events de acceso a files en todo el sistema
  • fatrace: informa events de acceso a files en todo el sistema

Como dijiste, iotop es una buena utilidad para la tarea, también puedes echarle un vistazo a estas herramientas:

  • lsof para ver los files por process.
  • dstat dar un informe en vivo sobre toda la actividad del sistema
  • sar puede darle una buena historia de la actividad de su sistema

(Mi toma anecdótica)

Sospecho que WordPress ha generado el tráfico de spam. Los sitios de WordPress son conocidos por sus tendencias de atraer spam si no los configuras.

Además, es posible que los spambots estén configurados para lanzar otro tipo de ataques en la instancia.

¿Ha configurado la instancia para mantener todos los puertos cerrados?