Problema: Recientemente renové uno de mis servidores, lo probé antes de usarlo y funciona bien, sin embargo, hace unos días, noté aproximadamente 4 veces la cantidad habitual de escrituras en el volumen raíz. Esto no es un problema de rendimiento: el servidor funciona bien.
Mi renovación fue bastante extensa (una reconstrucción completa), así que no tengo mucho para continuar en términos de causa. Brevemente, mis cambios incluyen:
- Actualización de Linux de Amazon (de 2011.02 a 2011.09), que también resultó en un cambio de ext3 a ext4 para el volumen raíz
- Pasando de php-fcgi a php-fpm (actualmente usando tcp)
- Pasar de una configuración de proxy inverso (nginx -> apache) a solo nginx
- Reemplazar vsftpd con pure-ftpd
- Reemplazar dkim-proxy con opendkim
- Reemplazar webmin con ispconfig
- Agregar barniz como capa de almacenamiento en caché para archivos dinámicos (exagerado por el volumen de visitas que obtienen estos sitios, pero es un experimento)
- Agregar una partición de intercambio
Configuración básica:
- Mi espacio de intercambio está montado en su propio volumen EBS (las escrituras en el volumen de intercambio son insignificantes). Esencialmente, he descartado esto como la causa (hay suficiente memoria libre, y ambas,
freeyiostatmuestran un uso mínimo de intercambio). - Mis datos (base de datos mysql, archivos de usuario (sitios web), todos los registros (desde / var / log), correo y archivos de barniz en su propio volumen EBS (usando
mount --bind). El volumen EBS subyacente se monta en/mnt/data - Mis archivos restantes (sistema operativo y aplicaciones de servidor central (por ejemplo, nginx, postfix, dovecot, etc.) son lo único en el volumen raíz: un total de 1.2GB.
La nueva configuración se ejecuta 'más suave' (más rápido, menos memoria, etc.) que el sistema anterior, y se ha mantenido estable durante 20 días (mediados de octubre), por lo que puedo decir, las escrituras elevadas han existido durante todo este tiempo .
Al contrario de lo que esperaría, tengo un volumen de lectura bajo (mis lecturas representan aproximadamente el 1.5% de mis escrituras, tanto en términos de bloques como de bytes en mi volumen raíz). No he cambiado nada en el volumen raíz (por ejemplo, nuevas instalaciones, etc.) en los últimos días, pero el volumen de escritura continúa siendo mucho mayor de lo esperado.
Objetivo: determinar la causa del aumento de escrituras en el volumen raíz (esencialmente, averiguar si es un proceso (y qué proceso), el sistema de archivos diferente (ext4) u otro problema (por ejemplo, memoria)).
Información del sistema:
- Plataforma: EC2 de Amazon (t1.micro)
- O / S: Amazon's Linux 2011.09 (derivado de CentOS / RHEL)
- Kernel de Linux: 2.6.35.14-97.44.amzn1.i686
- Arquitectura: 32 bits / i686
- Discos: 3 volúmenes EBS:
- xvdap1, root, sistema de archivos ext4 (montado con noatime)
- xvdf, datos, sistema de archivos xfs (montado con noatime, usrquota, grpquota)
- xvdg, swap
Los volúmenes raíz y de datos se capturan una vez al día; sin embargo, esta debería ser una operación de 'lectura', no de escritura. (Además, se utilizó la misma práctica en el servidor anterior, y el servidor anterior también era un t1.micro).
Los datos que me llevaron a investigar las E / S estaban en los detalles de mi última factura de AWS (que tenía E / S superiores a lo normal, no inesperado, ya que estaba configurando este servidor e instalando muchas cosas al principio del mes), y posteriormente en las métricas de CloudWatch para los volúmenes EBS adjuntos. Llego a la cifra '4 veces normal' extrapolando la actividad de E / S de noviembre (cuando no he alterado el servidor) para estimar un valor mensual y comparándolo con la E / S de los últimos meses cuando no estaba trabajando en mi servidor anterior (No tengo datos exactos de iostat de mi servidor anterior). La misma cantidad de escrituras ha persistido hasta noviembre, 170-330MB / h.
Información de diagnóstico (el tiempo de actividad de las siguientes salidas es de 20,6 días):
Métricas de Cloudwatch:
- volumen raíz (escritura): 5.5GB / día
- volumen raíz (lectura): 60 MB / día
- volumen de datos (escritura): 400 MB / día
- volumen de datos (lectura): 85 MB / día
- Volumen de intercambio (escritura): 3 MB / día
- volumen de intercambio (lectura): 2 MB / día
Salida de: df -h(solo para volumen raíz)
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 4.0G 1.2G 2.8G 31% /
El espacio utilizado no ha aumentado notablemente desde que se lanzó este sistema (lo que para mí sugiere que los archivos se actualizan, no se crean / anexan).
Salida de: iostat -x(con Blk_read, Blk_wrtnagregado en):
Linux 2.6.35.14-95.38.amzn1.i686 11/05/2011 _i686_
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s Blk_read Blk_wrtn avgrq-sz avgqu-sz await svctm %util
xvdap1 0.00 3.42 0.03 2.85 0.72 50.19 2534636 177222312 17.68 0.18 60.93 0.77 0.22
xvdf 0.00 0.03 0.04 0.35 1.09 8.48 3853710 29942167 24.55 0.01 24.28 2.95 0.12
xvdg 0.00 0.00 0.00 0.00 0.02 0.04 70808 138160 31.09 0.00 48.98 4.45 0.00
Salida de: iotop -d 600 -a -o -b
Total DISK READ: 6.55 K/s | Total DISK WRITE: 117.07 K/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO COMMAND
852 be/4 root 0.00 B 26.04 M 0.00 % 0.42 % [flush-202:1]
539 be/3 root 0.00 B 528.00 K 0.00 % 0.08 % [jbd2/xvda1-8]
24881 be/4 nginx 56.00 K 120.00 K 0.00 % 0.01 % nginx: worker process
19754 be/4 mysql 180.00 K 24.00 K 0.00 % 0.01 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
3106 be/4 mysql 0.00 B 176.00 K 0.00 % 0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
19751 be/4 mysql 4.00 K 0.00 B 0.00 % 0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
3194 be/4 mysql 8.00 K 40.00 K 0.00 % 0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
3156 be/4 mysql 4.00 K 12.00 K 0.00 % 0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
3099 be/4 mysql 0.00 B 4.00 K 0.00 % 0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
24216 be/4 web14 8.00 K 10.43 M 0.00 % 0.00 % php-fpm: pool web14
24465 be/4 web19 0.00 B 7.08 M 0.00 % 0.00 % php-fpm: pool web19
3110 be/4 mysql 0.00 B 100.00 K 0.00 % 0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
579 be/4 varnish 0.00 B 76.00 K 0.00 % 0.00 % varnishd -P /var/run/varnish.pid -a :80 -f /etc/varnish/default.vcl -T 127.0.0.1:6082 -t 3600 -w 1,1000,120 -u varnish -g varnish
582 be/4 varnish 0.00 B 144.00 K 0.00 % 0.00 % varnishd -P /var/run/varnish.pid -a :80 -f /etc/varnish/default.vcl -T 127.0.0.1:6082 -t 3600 -w 1,1000,120 -u varnish -g varnish
586 be/4 varnish 0.00 B 4.00 K 0.00 % 0.00 % varnishd -P /var/run/varnish.pid -a :80 -f /etc/varnish/default.vcl -T 127.0.0.1:6082 -t 3600 -w 1,1000,120 -u varnish -g varnish
587 be/4 varnish 0.00 B 40.00 K 0.00 % 0.00 % varnishd -P /var/run/varnish.pid -a :80 -f /etc/varnish/default.vcl -T 127.0.0.1:6082 -t 3600 -w 1,1000,120 -u varnish -g varnish
1648 be/4 nobody 0.00 B 8.00 K 0.00 % 0.00 % in.imapproxyd
18072 be/4 varnish 128.00 K 128.00 K 0.00 % 0.00 % varnishd -P /var/run/varnish.pid -a :80 -f /etc/varnish/default.vcl -T 127.0.0.1:6082 -t 3600 -w 1,1000,120 -u varnish -g varnish
3101 be/4 mysql 0.00 B 176.00 K 0.00 % 0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
19749 be/4 mysql 0.00 B 32.00 K 0.00 % 0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
19750 be/4 mysql 0.00 B 0.00 B 0.00 % 0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
19752 be/4 mysql 0.00 B 108.00 K 0.00 % 0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
19788 be/4 mysql 0.00 B 12.00 K 0.00 % 0.00 % mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
853 be/4 root 4.00 K 0.00 B 0.00 % 0.00 % [flush-202:80]
22011 be/4 varnish 0.00 B 188.00 K 0.00 % 0.00 % varnishd -P /var/run/varnish.pid -a :80 -f /etc/varnish/default.vcl -T 127.0.0.1:6082 -t 3600 -w 1,1000,120 -u varnish -g varnish
Para resumir lo anterior (y extrapolar a valores diarios) se ve, durante el período de 10 minutos:
- [flush-202] escribió 26MB = 3.6GB / día
- php-fpm escribió 17.5MB = 2.4GB / día
- MySQL escribió 684KB = 96MB / día
- Barniz escribió 580 KB = 82 MB / día
- [jbd2] escribió 528KB = 74MB / día
- Nginx escribió 120 KB = 17 MB / día
- El proxy IMAP escribió 8 KB = 1.1 MB / día
Curiosamente, parece que entre [flush-202]y php-fpmes posible dar cuenta del volumen diario de escrituras.
Utilizando ftop, soy incapaz de localizar ya sea la flusho php-fpmlas escrituras (por ejemplo ftop -p php-fpm.
Al menos parte de mi problema proviene de identificar qué procesos están escribiendo en el volumen raíz. De los mencionados anteriormente, que se puede esperar que todos sean escrito al volumen de datos (ya que los directorios pertinentes se enlace simbólico allí) (por ejemplo nginx, mysql, php-fpm, varnishdirectorios, apuntan a un volumen EBS diferente)
Creo que JBD2es el dispositivo de bloqueo de diario para ext4, y flush-202es el fondo de las páginas sucias. El dirty_ratioes 20 y el dirty_background_ratio10. La memoria sucia (de /proc/meminfo) era típicamente entre 50-150kB). El tamaño de página ( getconf PAGESIZE) es el valor predeterminado del sistema (4096).
Salida de: vmstat -s | grep paged
3248858 páginas paginada en 104625313 páginas paginada
Salida de: sar -B | grep Average
pgpgin/s pgpgout/s fault/s majflt/s pgfree/s pgscank/s pgscand/s pgsteal/s %vmeff
Average: 1.38 39.57 113.79 0.03 36.03 0.38 0.02 0.29 73.66
Lo anterior parece sugerir una gran cantidad de páginas paginadas; sin embargo, esperaría que las páginas se escribieran en mi partición de intercambio si fuera necesario, no en mi volumen raíz. De la memoria total, el sistema generalmente tiene 35% en uso, 10% en memorias intermedias y 40% en caché, 15% sin usar (es decir, 65% libre).
Salida de: vmstat -d
disk- ------------reads------------ ------------writes----------- -----IO------
total merged sectors ms total merged sectors ms cur sec
xvda1 105376 14592 2548092 824418 10193989 12264020 179666824 626582671 0 7872
xvdf 126457 579 3882950 871785 1260822 91395 30081792 32634413 0 4101
xvdg 4827 4048 71000 21358 1897 15373 138160 307865 0 29
vmstatmuestra consistentemente siy sovalores de 0
Salida de: swapon -s
Filename Type Size Used Priority
/dev/xvdg partition 1048572 9252 -1
En el presentimiento de que las escrituras de E / S pueden estar relacionadas con la memoria, deshabilité el barniz y reinicié el servidor. Esto cambió mi perfil de memoria a 10% en uso, 2% en memorias intermedias y 20% en caché, 68% sin usar (es decir, 90% libre). Sin embargo, durante una carrera de 10 minutos, iotop dio resultados similares a los anteriores:
- [flush-202] escribió 19MB
- php-fpm escribió 10MB
En la hora desde el reinicio, ya se han escrito 330 MB en el volumen raíz con 370 mil páginas intercambiadas.
Salida de inotifywatch -v -e modify -t 600 -r /[^mnt]*
Establishing watches...
Setting up watch(es) on /bin /boot /cgroup /dev /etc/ home /lib /local /lost+found /opt /proc /root /sbin /selinux /src /sys /usr /var
OK, /bin /boot /cgroup /dev /etc/ home /lib /local /lost+found /opt /proc /root /sbin /selinux /src /sys /usr /var is now being watched.
Total of 6753 watches.
Finished establishing watches, now collecting statistics.
Will listen for events for 600 seconds.
total modify filename
23 23 /var/log/
20 20 /usr/local/ispconfig/server/temp/
18 18 /dev/
15 15 /var/log/sa/
11 11 /var/spool/postfix/public/
5 5 /var/log/nginx/
2 2 /var/run/pure-ftpd/
1 1 /dev/pts/
Mirando un poco más allá de lo anterior, casi todas las escrituras se pueden atribuir a un proceso (desconocido) que se ejecuta cada 5 minutos y que verifica el estado de una variedad de servicios (como chkservden cPanel, pero no uso cPanel, y no instalé esto). Asciende a 4 archivos de registro (cron, maillog, ftp, imapproxy) actualizados durante los 10 minutos, y algunos elementos relacionados (sockets postfix, conexiones de ftpd puro). Los otros elementos son principalmente sesiones ispconfig modificadas, actualizaciones de contabilidad del sistema e intentos de acceso web no válidos (nombre_servidor inexistente) (registrados en / var / log / nginx).
Conclusiones y preguntas:
Permítanme comenzar diciendo que estoy un poco perplejo: generalmente soy bastante minucioso, pero siento que me falta algo obvio en este caso. Claramente, flushy php-fpmrepresentan la mayor parte de las escrituras, sin embargo, no sé por qué este podría ser el caso. En primer lugar, tomemos php-fpm: ni siquiera debería estar escribiendo en el volumen raíz. Sus directorios (tanto archivos como registros) están enlazados a otro volumen EBS. En segundo lugar, lo principal que debería escribir php-fpm son las sesiones y los cachés de página, que son pocos y pequeños, ciertamente no del orden de 1 MB / min (más como 1 K / min, si es así). La mayoría de los sitios son de solo lectura, con actualizaciones ocasionales. El tamaño total de todos los archivos web modificados en el último día es de 2.6 MB.
En segundo lugar, teniendo en cuenta el vaciado, las escrituras significativas me sugieren que las páginas sucias se descargan con frecuencia en el disco, pero dado que generalmente tengo un 65% de memoria libre y un volumen EBS separado para el espacio de intercambio, no puedo explicar por qué esto afectar las escrituras en mi volumen raíz, especialmente en la medida en que está ocurriendo. Me doy cuenta de que algunos procesos escribirán páginas sucias en su propio espacio de intercambio (en lugar de usar el espacio de intercambio del sistema), pero seguramente, inmediatamente después de un reinicio con la gran mayoría de mi memoria libre, no debería encontrarme con una cantidad sustancial de páginas sucias Si cree que esta es la causa, avíseme cómo puedo identificar qué procesos están escribiendo en su propio espacio de intercambio.
Es completamente posible que toda la idea de páginas sucias sea simplemente un arenque rojo y no esté completamente relacionada con mi problema (espero que sea realmente). Si ese es el caso, mi única otra idea es que hay algo relacionado con el diario ext4 que no estaba presente en ext3. Más allá de eso, actualmente estoy sin ideas.
Actualización (es):
6 de noviembre de 2011:
Conjunto dirty_ratio = 10y dirty_background_ratio = 5; actualizado con sysctl -p(confirmado a través de / proc); reran la prueba iotop de 10 minutos con resultados similares (flush escribió 17MB, php-fpm escribió 16MB, MySQL escribió 1MB y JBD2 escribió 0.7MB).
He cambiado todos los enlaces simbólicos que configuré para usar mount --binden su lugar. Barniz reactivado, servidor reiniciado; reran la prueba iotop de 10 minutos con resultados similares (flush escribió 12.5MB, php-fpm escribió 11.5MB, Varnish escribió 0.5MB, JBD2 escribió 0.5MB y MySQL escribió 0.3MB).
Al igual que en la ejecución anterior, mi perfil de memoria estaba 20% en uso, 2% en búferes y 58% en caché, 20% sin usar (es decir, 80% libre) En caso de que mi interpretación de memoria libre, en este contexto, sea defectuosa, Aquí está la salida de free -m(este es un t1.micro). total utilizado buffers compartidos gratuitos en caché Mem: 602 478 124 0 14 347 - / + buffers / caché: 116 486 Swap: 1023 0 1023
Alguna información adicional: Salida de: dmesg | grep EXT4
[ 0.517070] EXT4-fs (xvda1): mounted filesystem with ordered data mode. Opts: (null)
[ 0.531043] EXT4-fs (xvda1): mounted filesystem with ordered data mode. Opts: (null)
[ 2.469810] EXT4-fs (xvda1): re-mounted. Opts: (null)
También ejecuté ftop e iotop simultáneamente, y me sorprendió notar que las entradas que aparecían en iotop no aparecían en ftop. La lista ftop se filtró a php-fpm, ya que podía activar las escrituras de ese proceso de manera bastante confiable. Noté alrededor de 2 MB de escrituras por página vista para php-fpm, y aún no he descubierto lo que podría estar escribiendo, cualquier idea sobre la determinación de lo que se está escribiendo sería apreciada.
Intentaré apagar el diario en los próximos días y ver si eso mejora las cosas. Sin embargo, por el momento, me pregunto si tengo un problema de E / S o un problema de memoria (o ambos), pero estoy teniendo dificultades para ver el problema de memoria, si es que hay uno.
13 de noviembre de 2011:
Como el sistema de archivos usa extensiones, no fue posible montarlo como ext3, además, los intentos de montarlo como de solo lectura, simplemente resultaron en el montaje como lectura-escritura.
El sistema de archivos tiene el registro en diario habilitado (registro de 128 MB), como se desprende de lo siguiente:
Salida de: tune2fs -l /dev/sda1 | grep features
has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Según lo siguiente, se han escrito aproximadamente 140 GB en este volumen en poco menos de un mes, solo unos 5 GB / día.
Salida de: dumpe2fs -h /dev/sda1
Filesystem volume name: /
Last mounted on: /
Filesystem UUID: af5a3469-6c36-4491-87b1-xxxxxxxxxxxx
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 262144
Block count: 1048576
Reserved block count: 10478
Free blocks: 734563
Free inodes: 210677
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 511
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
RAID stride: 32582
Flex block group size: 16
Filesystem created: Wed Sep 21 21:28:43 2011
Last mount time: Sun Nov 13 16:10:11 2011
Last write time: Sun Oct 16 16:12:35 2011
Mount count: 13
Maximum mount count: 28
Last checked: Mon Oct 10 03:04:13 2011
Check interval: 0 (<none>)
Lifetime writes: 139 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
First orphan inode: 18610
Default directory hash: half_md4
Directory Hash Seed: 6c36b2cc-b230-45e2-847e-xxxxxxxxxxx
Journal backup: inode blocks
Journal features: journal_incompat_revoke
Journal size: 128M
Journal length: 32768
Journal sequence: 0x0002d91c
Journal start: 1
Continuando buscando archivos abiertos, intenté usar fuseren el volumen raíz:
Salida de: fuser -vm / 2>&1 | awk '$3 ~ /f|F/'
root 1111 Frce. dhclient
root 1322 frce. mysqld_safe
mysql 1486 Fr.e. mysqld
root 1508 Frce. dovecot
root 1589 Frce. master
postfix 1600 Frce. qmgr
root 1616 Frce. crond
root 1626 Frce. atd
nobody 1648 Frce. in.imapproxyd
postfix 1935 Frce. tlsmgr
root 2808 Frce. varnishncsa
root 25818 frce. sudo
root 26346 Fr.e. varnishd
postfix 26925 Frce. pickup
postfix 28057 Frce. smtpd
postfix 28070 Frce. showq
Nada inesperado, desafortunadamente. En caso de que fuera debido al hardware subyacente, restauré la instantánea del volumen raíz de ayer (nada había cambiado en el último día) y reemplacé el volumen raíz de la instancia con el nuevo. Como se esperaba, esto no tuvo ningún efecto sobre el problema.
Mi siguiente paso habría sido eliminar el diario, sin embargo, me topé con la solución antes de llegar a eso.
El problema radica en APC usando mmap respaldado por archivos. La fijación de esta caída de E / S de disco en aproximadamente 35x - a (aproximadamente) 150 MB / día (en lugar de 5 GB). Todavía podría considerar eliminar el diario, ya que parece ser el principal contribuyente restante de este valor, sin embargo, este número es bastante aceptable por el momento. Los pasos dados para llegar a la conclusión de APC se publican en una respuesta, a continuación.
watch. Solo había unos pocos archivos (17), en su mayoría archivos PID o archivos de bloqueo, con unos pocos archivos temporales (inexistentes). watch -d -n 0.5 'lsof / | grep REG | awk '"'"'$4 ~ /.*[wu]/ { print $9}'"'"' | sort -u'