¿Cómo puedo comprobar las limitaciones de rendimiento de mi servidor?
Indice
- Problemas de rendimiento generales
- Servidor Windows
- Servidor Linux
Problemas de rendimiento generales
Se habla de problemas de rendimiento cuando el servidor no funciona como debería o cómo se espera que lo haga. Los motivos pueden ser muy diversos. A menudo la causa se encuentra en un lugar inesperado. Esto hace que sea aún más importante aislar las causas y llegar al fondo de las mismas. Este artículo explica cómo hacerlo.
Tipos de problemas de rendimiento
Hay diferentes tipos de problemas de rendimiento, pero pueden ser similares en el funcionamiento del servidor. Aquí es muy importante encontrar el verdadero "cuello de botella".
Posibles problemas:
- Disco duro lento / SSD
¿Si un disco duro es muy lento, esto se puede ver sobre todo en un comportamiento muy lento al iniciar sesión y/o iniciar programas. Sin embargo, una vez iniciados los programas, todo suele funcionar con bastante rapidez. Los problemas suelen reaparecer cuando se utiliza el archivo o la partición de intercambio, o cuando es necesario volver a cargar o guardar datos. - Conexión de red lenta
Si la conexión de red está ocupada o es demasiado lenta, pueden producirse una gran variedad de problemas. Esto va desde una hora incorrecta hasta un mensaje de error al acceder a la página web. Dado que, especialmente en los servidores, muchas funciones y servicios dependen de que la conexión de red funcione correctamente, los tipos de problemas que aparecen son también muy diversos. - Sobrecarga en el sistema o de la CPU ( High System Load or High CPU utilization)
Una alta carga de la CPU o de todo el sistema es probablemente el caso más conocido de problemas de rendimiento. Se produce un retraso general en la visualización y también en los tiempos de respuesta. El servidor no responde como cabría esperar.
¿Esporádico o permanente?
Es muy importante distinguir si los problemas que experimentas al utilizar el servidor de STRATO son permanentes o si solo se producen en determinados momentos. Si se trata de un comportamiento esporádico, comprueba también si puedes identificar un patrón (por ejemplo, todos los jueves a las 13:00 horas).
Si observas un patrón, comprueba si alguna tarea programada (por ejemplo, una copia de seguridad) puede ser la causa y vuelve a programarla. Si la hora de los problemas de rendimiento varía, entonces ya has encontrado la causa.
Supervisión y registros del servidor
SLos registros que normalmente genera el sistema pueden proporcionar las primeras pistas sobre la causa de los problemas de rendimiento. Por eso siempre vale la pena comprobar los registros del sistema.
En Linux puedes ver los registros del kernel utilizando sudo dmesg (esto mostrará principalmente errores de hardware como problemas de disco duro). Puedes obtener más registros con el comando journalctl (aquí vale la pena echar un vistazo a la página man para las diferentes opciones) o en los archivos de registro directamente en /var/log.
En Windows, el Visor de Sucesos de la Administración de Equipos es el que contiene los registros. Es importante el uso de los diferentes filtros, porque aquí se recogen todos los eventos. Incluso con un sistema que funciona normalmente es normal que aparezcan varias advertencias o incluso errores.
Siempre se recomienda una herramienta de monitorización para el servidor. Son muy útiles para averiguar el motivo de las caídas de nuestro servidor. Es difícil comprobar lo que ocurre en el servidor cuando los problemas de rendimiento son graves.
Hay muchas herramientas de monitorización tanto para Linux como para Windows. Van desde un simple registro de algunos datos clave en un archivo de log hasta soluciones completas con registro y presentación de los datos de varios servidores.
En general, se distingue entre la monitorización en tiempo real y a largo plazo. Con la monitorización en tiempo real, los datos se recuperan con más frecuencia, pero no se almacenan durante tanto tiempo. Aquí rara vez se puede retroceder más de una hora. En cambio, la monitorización a largo plazo conserva los datos durante más tiempo (aquí se puede retroceder días, semanas o incluso meses o años, según la configuración). Sin embargo, los datos no se consultan con tanta frecuencia.
Algunos ejemplos de sistemas de monitorización son Netdata, collectd, Nagios y Prometheus. Grafana no es un sistema de monitorización en sí, sino que sirve para procesar los datos recogidos (también de diferentes fuentes).
En Windows, la supervisión en tiempo real también está disponible en la pestaña "Rendimiento" del Administrador de tareas. Para obtener información más detallada, puedes consultar el monitor de recursos desde aquí. En este caso, también se puede filtrar, por ejemplo, el uso elevado de la red.
Servidor Windows
En un servidor Windows, el primer lugar al que hay que acudir para comprobar el estado actual es la pestaña Rendimiento del Administrador de tareas. El Administrador de tareas se abre mediante la combinación de teclas "Ctrl+Shift+Esc" o es accesible a través del menú que se abre al hacer clic con el botón derecho del ratón en el icono de Windows.
Al igual que con todas las pruebas de rendimiento, es mejor ejecutar las pruebas varias veces y en diferentes momentos del día. Esta es la única manera de obtener una visión general significativa del rendimiento del servidor. Una sola prueba es solo una instantánea de la situación actual.
En el caso de las restricciones temporales, las pruebas deben realizarse mientras se produce la restricción. Los valores medidos en estado normal, cuando todo funciona, no son de ayuda en este caso.
Prueba de los discos duros / rendimiento de SSD
La forma más sencilla de comprobar el rendimiento del disco duro en Windows es utilizar la evaluación de rendimiento de Windows. Para ello, existe una herramienta llamada winsat accesible desde el símbolo del sistema (Windows Server 2016) o Powershell (Windows Server 2019). Ambos deben abrirse con derechos de administrador.
Para probar la velocidad de lectura, introduce:winsat disk -seq -read -drive X
Para probar la velocidad de escritura, utiliza:winsat disk -seq -write -drive X
Sustituye la X por la letra de la unidad correspondiente (normalmente C y/o D). Por ejemplo, un resultado podría ser el siguiente:
Prueba de la conexión de red
Se puede realizar una prueba de la conexión de red a través de las diferentes pruebas de velocidad que también se utilizan para probar la conexión a Internet en casa. En este caso, es aconsejable realizar estas pruebas en diferentes momentos y también con diferentes proveedores.
Un ejemplo de prueba puede ser:
Carga de CPU y de sistema
Para la carga de la CPU y del sistema en general, el primer lugar en el que hay que fijarse es la pestaña Rendimiento del Administrador de tareas y el Monitor de recursos de Windows.
También puedes ejecutar pruebas especiales de estrés de la CPU si sospechas que una carga de trabajo elevada está causando inestabilidad. Para ello, existen programas especiales de otros proveedores que debes instalar explícitamente. Sin embargo, en el caso de los Servidores Virtuales, la importancia es limitada porque los resultados dependen en gran medida del estado actual de la virtualización.
Si tienes un servidor con STRATO Server-Cloud-Panel, puedes habilitar la monitorización (y preferiblemente instalar un agente de monitorización). Esto significa que los valores también se pueden leer directamente en el Cloud Panel.
Casos especiales
Alta carga de la memoria principal con un Servidor Virtual Windows
¿El indicador de la memoria en el administrador de tareas de tu Servidor Virtual Windows es muy alto? Te explicamos por qué. El indicador de la memoria disponible está parcialmente por debajo del tamaño de la memoria garantizada de tu servidor virtual Windows.
La razón de ello es la gestión de la memoria de la plataforma de virtualización, porque la asignación de la memoria se realiza de forma dinámica. Tu servidor virtual Windows siempre tiene asignada la cantidad de memoria que necesita actualmente, además de un pequeño búfer. Si la carga aumenta, el tamaño de la memoria asignada también aumenta.
Las aplicaciones de tu servidor virtual Windows requieren 1,2 gigabytes de memoria y se les asigna 1,44 gigabytes de memoria. Si el requerimiento de memoria de tu servidor aumenta a 2 gigabytes, el requerimiento de memoria asignada aumenta entonces a 2.4 gigabytes. El aumento del tamaño de RAM es posible hasta por lo menos el tamaño de RAM garantizada de tu servidor virtual.
Datos que necesita el soporte
Si no has podido encontrar una causa para las fluctuaciones de rendimiento sobre la base de la información proporcionada hasta ahora, puedes contactar con el soporte. Es posible que necesitemos datos y valores:
- ¿Cómo aparecen exactamente los problemas de rendimiento?
Ejemplo: "El sitio web xyz.es carga muy lentamente" o "Carga y descarga muy lentas en el servidor" - ¿Cuándo se produce exactamente el problema de rendimiento?
Ejemplo: "Siempre desde hace 2 días" o "Todos los viernes a las 15:00 horas". - ¿Qué versión de Windows utilizas exactamente?
- ¿Se han instalado todas las actualizaciones?
- Los valores de rendimiento de los discos duros / SSD (ver arriba)
- En caso de un disco duro o SSD defectuoso, al menos el número de serie del disco duro que todavía está bien (se puede leer, por ejemplo, con las smartmontools para Windows).
- Información de la pantalla de eventos de Windows (filtrada)
- Las conexiones de red y los resultados de la carga y descarga (ver arriba)
- Las evaluaciones de los procesos y la ocupación de la memoria
- Visualización de la carga de la CPU y del sistema (ver arriba)
- En función de la disponibilidad, también los valores de la monitorización a largo plazo.
Servidor Linux
Para llegar al fondo de los problemas de rendimiento de un servidor Linux, necesitamos ciertos datos y los resultados de varias pruebas.
Al igual que con todas las pruebas de rendimiento, es mejor ejecutar las pruebas varias veces y en diferentes momentos del día. Esta es la única manera de obtener una visión general significativa del rendimiento del servidor. Una sola prueba es solo una instantánea de la situación actual.
En el caso de las restricciones temporales, las pruebas deben realizarse mientras se produce la restricción. Los valores medidos en estado normal, cuando todo funciona, no ayudan.
Prueba de los discos duros / rendimiento de SSD
Para probar el rendimiento de los discos duros o dado el caso del disco SSD, utiliza el comando FIO (Flexible IO Tester).
FIO es una herramienta de evaluación comparativa y simulación de cargas de trabajo para Linux/Unix, que también mantiene la capa de bloques del núcleo de Linux
Es posible que tengas que instalarlo en tu distribución. La ventaja en este caso es que ofrece resultados realistas incluso con una conexión de memoria como la que se utiliza con nuestros Servidores Virtuales. Una prueba con dd no es representativa debido a la diferente tecnología de almacenamiento utilizada. Deberás seguir estos pasos:
Para una prueba de la velocidad de escritura:
sudo fio --rw=write --name=FIO --size=1G --filename=testfile
Se crea un archivo de 1 GB llamado "testfile". Este también se puede utilizar para la siguiente prueba.
FPara una prueba de velocidad de lectura:
sudo fio --rw=read --name=FIO --size=1G --filename=testfile
Una vez terminadas las pruebas con fio se puede borrar el archivo "testfile":
sudo rm testfile
Una partición muy llena también puede provocar problemas de rendimiento. Por lo tanto, comprueba espacio de las particiones:sudo df -h
También es interesante la ocupación de los iNodes, ya que incluso con la escasez de inodes pueden producirse problemas de rendimiento:sudo df -hi
En el caso de un servidor dedicado, un disco duro o SSD parcial o totalmente defectuoso también puede ser una posible causa. Si sospechas que este es el caso, inicia el servidor en el sistema de rescate y comprueba lo siguiente:
¿Se han reconocido todos los discos duros?
Comando: lsblk
Aquí se muestran los discos duros reconocidos y sus particiones. El disco duro o el propio SSD se puede encontrar como sda y/o sdb y quizás sdc. ¿Coincide el número y el tamaño detectado con la información de tu servidor?
Las unidades (disco duro y SSD) tienen algunas capacidades de autocomprobación a través de SMART, que puedes utilizar para mostrar los valores de SMART. La información básica sobre el disco duro está disponible con:
smartctl -i /dev/sdX
Puedes obtener una edición completa con
smartctl -a /dev/sdX
(Sustituye la X por la letra correspondiente según la pantalla de lsblk).
También puedes redirigir la salida de lsblk y smartctl a un archivo y enviárnoslo para que lo analicemos. En cualquier caso, consulta previamente con nuestro Soporte.
Prueba de la conexión de red
Para mostrar las conexiones de red actualmente abiertas, utiliza el siguiente comando:
sudo ss -tpn
Si los problemas de conexión solo afectan a determinados servicios o programas (por ejemplo, el servidor web), también puedes comprobar en el servidor qué procesos están esperando conexiones desde el exterior:
sudo ss -tulpn
Con los Servidores Virtuales Linux el número de conexiones simultáneas está limitado. Por favor, comprueba en el archivo /proc/user_beancounters los valores "numtcpsock" (número máximo de conexiones TCP) y "numothersock" (número máximo de conexiones no TCP, esto incluye los sockets locales de Unix).
Para probar la velocidad de la red, recomendamos cargar y descargar un archivo grande desde y hacia otro servidor o un Almacenamiento en la nube. Aquí deberías utilizar un programa que muestre la velocidad de transferencia (por ejemplo, wget, curl o scp).
No recomendamos hacer una prueba con "speedtest" o "speedtest-cli", porque puede llevar a resultados erróneos, dependiendo de la versión y el entorno utilizados.
EPuedes probar la pérdida de paquetes con un ping. La forma más fácil de hacerlo es desde el puesto de trabajo. Abre una línea de comandos (o un terminal) y haz un ping al servidor:
Linux: ping -c <Número> <Dirección-Servidor>
Windows: ping -n <Número> <Dirección-Servidor>
En cuanto al número, debe elegirse de forma que sea posible estimar cuántos paquetes se perderán. Se recomienda hacer pruebas con al menos 10 o 20 paquetes.
En caso de problemas de conexión, la información mediante un traceroute también puede ayudar. Aquí se rastrea el camino que sigue un paquete. De nuevo, puedes iniciar la prueba desde tu ordenador utilizando una línea de comandos o un terminal.
Linux: traceroute <Server-Adresse>
Windows: tracert <Server-Adresse>
Carga de CPU y de sistema
Puedes obtener una visión general de la carga actual de la CPU con el programa top (terminar la visualización con la tecla q). En la clasificación por defecto, el proceso que consume más energía de la CPU se muestra en la parte superior.
Puedes obtener una mejor visión de conjunto con el programa htop, se suele tener que instalar adicionamente.
Con este comando se puede generar una lista completa de los procesos que se están ejecutando actualmente:
sudo ps -ely
También se puede visualizar la ocupación de memoria. Aquí también se muestra el uso de la memoria de intercambio (swap):
sudo free -h
El uso de la memoria de intercambio suele provocar importantes caídas de rendimiento, incluso cuando se intercambia a un SSD.
Una ocupación alta de la memoria también puede ser causada por un error de programa o de configuración. Otra posible causa es un número alto de accesos (a la página web) y es una indicación de que el sistema actual es simplemente demasiado pequeño para los requisitos.
Casos especiales
Límites del Servidor Virtual Linux
Los Servidores Virtuales Linux están sujetos a ciertas limitaciones. Por favor, comprueba también los límites superados en el archivo /proc/user_beancounters. En el archivo, la última columna muestra las veces que se ha superado el límite respectivo desde el último arranque del sistema.
Superar algunos valores puede llevar a que no se puedan iniciar más procesos nuevos. A pesar de ello, algunos programas lo intentan una y otra vez y aumentan la carga del sistema.
Si se superan los límites con un funcionamiento normal, ponte en contacto con nuestro Soporte. Aquí se puede determinar si es útil una actualización del servidor.
Procesos contra hilos en Servidores Virtuales Linux
¿No puedes iniciar nuevos procesos aunque no se hayan superado los límites anteriores? ¿Recibes mensajes de que no hay suficiente memoria libre, aunque todavía hay suficiente memoria?
En este caso se trata de una limitación por una configuración del propio Linux. El valor de esto se llama "DefaultTasksMax".
Para determinar el valor límite actual, introduce el siguiente comando en shell:
systemctl show --property=DefaultTasksMax
Para ver el límite actual, introduzca el siguiente comando en el shell:systemctl show --property=DefaultTasksMax
Este valor especifica cuántos hilos puede iniciar un proceso. Puedes cambiar el valor según tus necesidades en el archivo /etc/systemd/system.conf Por favor, reinicia el servidor después de hacer un cambio para que la nueva configuración se active por completo.
Este valor se puede establecer en estos archivos:
/etc/systemd/system.conf
/etc/systemd/system.conf.d/*.conf
/run/systemd/system.conf.d/*.conf
/usr/lib/systemd/system.conf.d/*.conf
/etc/systemd/user.conf
/etc/systemd/user.conf.d/*.conf
/run/systemd/user.conf.d/*.conf
/usr/lib/systemd/user.conf.d/*.conf
Por favor, comprueba estos archivos si has realizado un cambio en el valor pero no se ha implementado.
Encontrarás más información sobre los parámetros configurables mediante:
man systemd-system.conf
Alta carga mediante rsyslogd (Ubuntu 12.04 y 14.04))
Al usar Ubuntu 14.04. y Ubuntu 12.04. se produce un error conocido con el rsyslogd. El resultado es un aumento de la carga del sistema. El error ya no se produce en las nuevas versiones de Ubuntu.
La causa es el registro del kernel activado en el archivo de configuración del rsyslogd. Esto no funciona con la plataforma de virtualización que utiliza STRATO.
Puedes comprobar en pocos pasos si este error es responsable de un aumento de carga en tu Servidor Virtual.
1. Comprobación del Logfiles
Comprueba si las siguientes líneas se emiten repetidamente en el archivo de registro de tu servidor virtual en /var/log/syslog:
Nov 12 18:22:19 h123456 rsyslogd: message repeated 498 times: [imklog: error reading kernel log - shutting down: Bad file descriptor]Nov 12 18:22:25 h123456 rsyslogd-2177: rsyslogd[internal_messages]: 2954152 messages lost due to rate-limiting
2. Comprueba la carga ( Load ) de tu servidor
Puedes conocer la carga de tu servidor mediante acceso SSH y el comando top. Para ello, conéctate a tu servidor usando el programa putty e introduce el comando top
En el resultado siguiente puedes ver la carga de las tareas individuales de tu servidor. Comprueba el comando rsyslogd y la carga de CPU para esta tarea.PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND371 syslog 20 0 261940 1500 944 S 100,1 0,0 2:00.82 rsyslogd
Si esta tarea tiene una carga de CPU muy alta, es responsable de los problemas de rendimiento de tu servidor virtual. Puedes arreglar el error en pocos pasos.
3. Corrección del error
Detén el servicio rsyslogd. Para ello, usa el comando:
sudo service rsyslog stop
En este paso se desactiva el registro del núcleo. Para ello, usa el comando:
sudo sed -i -e 's/^\$ModLoad imklog/#\$ModLoad imklog/g' /etc/rsyslog.conf
También puedes comprobar el archivo /etc/rsyslog.conf usando un editor y comentar la línea:
$ModLoad imklog # provides kernel logging support
Para hacer un comentario, pon un # delante de la línea.
4. Vuelve a arrancar el servicio rsyslogd
Para ello, usa el comando:
sudo service rsyslog start
El servicio rsyslogd ya no afectará excesivamente al rendimiento de tu servidor virtual.
Datos que necesita el soporte
Si no has podido encontrar una causa para las fluctuaciones de rendimiento sobre la base de la información proporcionada hasta ahora, puedes contactar con el soporte. Nuestros compañeros necesitan ciertos datos para hacer una buena comprobación. Son los siguientes:
- ¿Cómo aparecen exactamente los problemas de rendimiento?
Ejemplo: "El sitio web xyz.es carga muy lentamente" o "Carga y descarga muy lentas en el servidor" - ¿Cuándo se produce exactamente el problema de rendimiento?
Ejemplo: "Siempre desde hace 2 días" o "Todos los viernes a las 15:00 horas". - ¿Se han instalado todas las actualizaciones de la distribución correspondiente?
- Los valores de medición para los discos duros / SSD (ver arriba)
- En el caso de un disco duro o SSD defectuoso, al menos el número de serie del disco duro que todavía está bien (se puede leer con smartctl, por ejemplo).
- Las conexiones de red y los resultados de la carga y descarga (ver arriba)
- Las evaluaciones de los procesos y el uso de la memoria (ver arriba).
- El resultado del registro del núcleo (
sudo dmesg) - Para los Servidores Virtuales Linux: Contenido del archivo
/proc/user_beancounters