La instalación del Oracle Linux fue relativamente rápida, pero la instalación del Oracle Database 19c utilizando el paquete RPM, fue bastante dolorosa. Algo que realmente no me esperaba.
Ese día simplemente apagué la máquina virtual y me retiré con alguna desazón.
Hoy he tenido un poco más de tiempo y volví a arrancar la VM y validar el motivo de dicha lentitud.
Vaya, me he dado cuenta, después de casi 20 minutos levantando el LISTERNER y el contenedor de la base de datos, que no tengo memoria disponible. He definido mi VM con 8GB de RAM y 4 hilos de procesamiento.
[root@lab2 ~]# uname -a
Linux lab2.oracle.com 4.14.35-1844.4.5.el7uek.x86_64 #2 SMP Tue Apr 9 00:29:47 PDT 2019 x86_64 x86_64 x86_64 GNU/Linux
[root@lab2 ~]#
Entonces me dí la tarea de buscar la causa de dicho desastre.
Sorpresa, OL 7.6 genera algunos problemas con mi HW. ( En instantes les explico esta parte ). He recibido el siguiente mensaje cuando tan sólo deseaba cambiarme al superusuario del sistema operativo.
[oracle@lab2 ~]$ su - root
Password:
Last login: Sun May 5 14:57:01 CST 2019 on pts/1
'abrt-cli status' timed out
[root@lab2 ~]#
[root@lab2 ~]# sync; echo 3 > /proc/sys/vm/drop_caches
Ahora reviso nuevamente y he logrado recuperar una gran cantidad de mi memoria física.
[root@lab2 ~]# top
top - 14:34:20 up 47 min, 3 users, load average: 7.02, 15.90, 14.72
Tasks: 311 total, 3 running, 228 sleeping, 0 stopped, 0 zombie
%Cpu(s): 14.2 us, 19.5 sy, 4.7 ni, 4.8 id, 46.2 wa, 0.0 hi, 10.7 si, 0.0 st
KiB Mem : 8158724 total, 5885004 free, 1130388 used, 1143332 buff/cache
KiB Swap: 8257532 total, 8257532 free, 0 used. 6261344 avail Mem
Aún así, la VM aún esta lenta, pero ahora tengo suficiente memoria física disponible. Validando los procesos ejecutándose a nivel de sistema operativo, me encuentro un proceso con el mismo nombre del error que obtuve cuando estaba haciendo el comando "su".
Si efectivamente al "googlelear" dicho proceso, me encuentro varias notificaciones de BUGs operativos en distintos distros de linux.
Proceso a matar el proceso seguidamente.
[root@lab2 ~]# kill -9 3225
[root@lab2 ~]# ps -ef|grep watch
root 11 2 0 13:46 ? 00:00:00 [watchdog/0]
root 14 2 0 13:46 ? 00:00:00 [watchdog/1]
root 20 2 0 13:46 ? 00:00:00 [watchdog/2]
root 26 2 0 13:46 ? 00:00:00 [watchdog/3]
root 47 2 0 13:46 ? 00:00:00 [watchdogd]
root 3228 1 0 13:51 ? 00:00:01 /usr/bin/abrt-watch-log -F Backt
root 9463 9222 37 14:37 pts/1 00:00:00 grep --color=auto watch
Luego he encontrado dentro de la documentación de Red Hat y Fedora, que estos 4 servicios a continuación, deben ser deshabilitados para evitar el problema.
[root@lab2 ~]# service abrt stop
[root@lab2 ~]# service abrt-ccpp stop
Redirecting to /bin/systemctl stop abrt-ccpp.service
[root@lab2 ~]# chkconfig abrt-ccpp off
Note: Forwarding request to 'systemctl disable abrt-ccpp.service'.
Removed symlink /etc/systemd/system/multi-user.target.wants/abrt-ccpp.service.
[root@lab2 ~]# service abrtd stop
Redirecting to /bin/systemctl stop abrtd.service
[root@lab2 ~]# chkconfig abrtd off
Note: Forwarding request to 'systemctl disable abrtd.service'.
Removed symlink /etc/systemd/system/multi-user.target.wants/abrtd.service.
[root@lab2 ~]# service abrt-oops.service stop
Redirecting to /bin/systemctl stop abrt-oops.service
[root@lab2 ~]# chkconfig abrt-oops off
Note: Forwarding request to 'systemctl disable abrt-oops.service'.
Removed symlink /etc/systemd/system/multi-user.target.wants/abrt-oops.service.
[root@lab2 ~]# service abrt-vmcore stop
Redirecting to /bin/systemctl stop abrt-vmcore.service
[root@lab2 ~]# chkconfig abrt-vmcore off
Note: Forwarding request to 'systemctl disable abrt-vmcore.service'.
Removed symlink /etc/systemd/system/multi-user.target.wants/abrt-vmcore.service.
[root@lab2 ~]#
Ahora sí, después de varios minutos, el comportamiento normal a nivel de rendimiento se mantiene en mi máquina virtual y puedo sin problemas continuar con mis laboratorios.
No hay comentarios:
Publicar un comentario
Te agradezco tus comentarios. Te esperamos de vuelta.