- ACPI: Looking for DSDT in initramfs... error, file /DSDT.aml not found.
- ifconfig[2844]: segfault at xxxxx error 4
- Dec 21 13:55:05 hosting2-front02 kernel: Clocksource tsc unstable (delta = 4688700040 ns)
- kernel: checking TSC synchronization [CPU#0 -> CPU#1]: passed. kernel: checking TSC synchronization [CPU#0 -> CPU#2]: passed. kernel: checking TSC synchronization [CPU#0 -> CPU#3]: kernel: Measured 6 cycles TSC warp between CPUs, turning off TSC clock. kernel: Marking TSC unstable due to: check_tsc_sync_source failed. kernel: Brought up 4 CPUs
- Haciendo vmstat o top: Floating point exception.
- Al hacer df -h overflow 1.0M 4.0K 1020K 1% /tmp
He googleado por semanas, tratando de atar cabos, y de encontrar el por que de este comportamiento aleatorio e inesperado. En la busqueda encontre indicios de DDoS (Denegación de servicio) mediante syn flooding, algo que corregi por medio de mod-evasive,iptables e tunning TCP en el kernel de Linux.
A pesar de haber hecho los ajustes necesarios, el comportamiento se sigue repitiendo, el sistema operativo se congela una vez al día, durante la madrugada donde las cargas son menores. Mi ambiente de producción es el siguiente:
A pesar de haber hecho los ajustes necesarios, el comportamiento se sigue repitiendo, el sistema operativo se congela una vez al día, durante la madrugada donde las cargas son menores. Mi ambiente de producción es el siguiente:
- Linux 2.6.24-19-virtual #1 SMP Thu Aug 21 00:52:59 UTC 2008 i686 GNU/Linux
- Ubuntu JeOS Server 8.04.3 LTS
- Servidor de aplicaciones web Apache 2.2.8 Server.
- Cuatro procesadores Intel(R) Xeon(R) CPU X5450 @ 3.00GHz
- 3805 Mb de RAM.
- kernel: Marking TSC unstable due to: check_tsc_sync_source failed.
Al investigar al respecto, descubro que existe problemas de sincronizacion entre el host de virtualizacion (ESX 3.5 en mi caso) y los huespedes (Linux guest), existen salto de reloj o desincronización entre ambos, el clock real de las interrupciones y la BIOS virtual proporcionada al sistema invitado. En los kernel 2.6.X la correcciones se basan en algoritmos mejorados que pueden producir saltos hacia delante o hacia a tras en el Linux guest, lo que proboca descontinuidad en le sistema huesped. Estas versiones de kernels introducen la temporización y metodos de correccion mediante la API ACPI del kernel, el clocksource. Estas correcciones son las que provocan que nuestro servidor proporcione inexactitud a nuestras aplicaciones y hanging del servidor.
Como solucionarlo, esta documentado por vmeware aqui por lo que no voy a perder tiempo en explicarlo. En las recomendaciones de este documento esta la utilización del servicio NTP, lo cual en mi caso fue necesario para poder solucionar el problema, ya que al pasarle al kernel el clocksource=acpi_pm, no fue suficiente. Aclaro que la comunicación NTP es bidireccional en el puerto UDP 123, es decir nuestros firewalls deben dejar entrar y salir estos puertos para que la sincronización tenga efecto. Los comando NTP lo trate en un entrada anterior.
"La formulación de un problema, es más importante que su solución."Como solucionarlo, esta documentado por vmeware aqui por lo que no voy a perder tiempo en explicarlo. En las recomendaciones de este documento esta la utilización del servicio NTP, lo cual en mi caso fue necesario para poder solucionar el problema, ya que al pasarle al kernel el clocksource=acpi_pm, no fue suficiente. Aclaro que la comunicación NTP es bidireccional en el puerto UDP 123, es decir nuestros firewalls deben dejar entrar y salir estos puertos para que la sincronización tenga efecto. Los comando NTP lo trate en un entrada anterior.
EINSTEIN, Albert
Referencias:
