Rendimiento del servidor

Rendimiento del servidor

Tenemos un servidor dedicado que utilizamos para organizar sitios web (nuestro servidor de prueba). El rendimiento del servidor ha empeorado mucho y tenemos que reiniciarlo periódicamente. Cuando el rendimiento es deficiente, revisé el administrador de tareas para ver los procesos y la memoria, pero todo parece estar bien.

Usamos un sistema de administración de contenido y siempre cuando usamos la sección de administración de este CMS notamos la degradación del rendimiento, lo que me hace pensar que puede tener algo que ver con las llamadas a la base de datos que realiza el CMS.

¿Suena esto viable? ¿Alguna otra sugerencia sobre cómo puedo probar esto?

Gracias de antemano...

Respuesta1

¿Suena esto viable?

Sí.

¿Alguna otra sugerencia sobre cómo puedo probar esto?

Comprobación de rendimiento. Tenga en cuenta que el rendimiento no es sólo de la CPU. Si cree que la base de datos es el problema, es posible que esté vinculada a IO: en este caso, el porcentaje de latencia/actividad del disco se disparará. Verifique los contadores de rendimiento del disco. Especialmente si tiene IO, la CPU será baja ya que la CPU básicamente no atiende los procesos porque está esperando a que finalice IO.

Por lo general, las bases de datos cada vez más ocupadas requieren presupuestos de E/S importantes, lo que significa bastantes discos. Tengo una base de datos aquí que ahora usa 6 discos de 10k RPM y pronto se actualizará a 8, SÓLO para los datos. Un típico servidor dedicado barato a menudo tiene presupuestos de IO realmente malos: los discos lentos y grandes del usuario final, pocos de ellos, no constituyen un subsistema rápido. Esto funciona bastante bien en algunos escenarios, pero al final podría resultar sobrecargado.

Respuesta2

Como dijo TomTom, esto es casi con certeza una indicación de que su sistema está vinculado a IO, no a CPU. La causa raíz podría ser simplemente el aumento de la carga de la base de datos detrás de su CMS o podría ser otra cosa, pero en cualquier caso, PerfMon tiene algunos contadores útiles para observar que pueden indicarle con certeza si el subsistema de disco es la causa.

\DiscoLógico\Promedio. Disco Seg/Lectura y \LogicalDisk\Avg. Segundo disco/escritura
Estos son sus números de latencia básicos para operaciones de E/S de lectura y escritura; cuanto más bajos, mejor. Cada vez que estos números superen los 15 ms, el rendimiento del servidor será notablemente pobre.

\LogicalDisk\Disk Bytes/Sec y \LogicalDisk\Disk Reads/Sec y Esto le indicará el rendimiento general del disco. Estas velocidades pueden estar saturando la capacidad máxima del subsistema de disco, ya sea debido únicamente al rendimiento o porque ha alcanzado un límite de IOP para su patrón de lectura/escritura. Puede ser difícil deducir algo significativo de esto a menos que esté 100% seguro de que tiene un patrón de IO predecible. No hay una forma realmente útil de dar un número específico a tener en cuenta aquí, pero si ve 50-100 MBytes/seg o más en un solo disco SATA, eso sería tan bueno como podría esperar ver. Los discos de servidor más rápidos (10k, 15K, SSD) pueden superar eso y el almacenamiento conectado a SAN puede ofrecer prácticamente lo que desee, siempre que pague lo suficiente. Con IO aleatoria pequeña (típica de operaciones de base de datos), este número siempre será bajo y no dice mucho.

\LogicalDisk\Disk Writes/seg, \LogicalDisk\Disk Reads/seg y \LogicalDisk\Disk Transfers/seg Estos le indicarán el número de operaciones de E/S discretas por segundo y la relación Lectura/Escritura. Los discos giratorios son bastante limitados en este sentido: los discos SATA de 7,2K pueden soportar alrededor de 70-80 IO por segundo, los discos de 10K lo llevan al rango de 100-150, los de 15K serán 200+. Los SSD serán uno o dos órdenes de magnitud más altos. Los grupos RAID aumentan esto de manera bastante lineal para las lecturas, pero las escrituras incurrirán en una penalización de entre 2 y 5. Un paquete RAID 5 de 3 unidades (con una penalización de escritura de 4) admite aproximadamente un 25 % menos de E/S de escritura que una sola unidad, por ejemplo.

Si este número tiende a aumentar mientras la latencia aumenta a territorio peligroso (es decir, > 15 ms), es una fuerte indicación de que sus discos están alcanzando un límite de IOP, independientemente de los números específicos informados.

\Disco lógico\E/S divididas/seg Esto le indicará cuántas solicitudes de IO dan como resultado múltiples operaciones y le dará una idea de cuánta fragmentación está afectando la actividad de IO.

Disco físico: longitud actual de la cola del disco y disco físico: promedio. Longitud de la cola del disco. Esto le indica cuántas E/S pendientes están en espera de completarse en el nivel del disco físico. Si esto es 2 o más en un solo disco, o excede la cantidad de discos en el grupo RAID a partir del cual se construye el disco, es posible que esté insertando más E/S en el disco de las que puede completar de manera oportuna. Hay escenarios en los que esto no importa demasiado, pero será un verdadero problema para los sistemas que requieren E/S de disco de baja latencia (bases de datos donde el almacenamiento en caché de memoria no puede cubrir la debilidad de los discos). La primera es una lectura instantánea, así que solo preocúpese si es constantemente alta o cambia en línea con el contador de % de tiempo de disco. Si el promedio. La longitud de la cola del disco es demasiado alta, entonces definitivamente tienes un problema.

Disco físico: % de tiempo de disco El % de tiempo de disco le indica qué tan ocupado está el disco. A medida que se acerque al 100%, tendrá dificultades para que el sistema haga cualquier otra cosa que dependa de ese disco, ya que todas las E/S adicionales tenderán a estar en cola. Incluso números significativamente por debajo del 100% pueden indicar un problema y si este es alto o está aumentando, y la longitud de la cola de disco actual es alta, es una clara indicación de una carga de E/S que excede la capacidad de los discos. En realidad, este número se calcula de una manera extraña y, como resultado, podría no ser tan útil para analizar el rendimiento de RAID.

Este artículo del blog de Technetprofundiza mucho más en algunos de estos contadores y en algunos escenarios en los que puede utilizarlos para identificar el problema y establecer cómo solucionarlo.

Respuesta3

¿Vale la pena considerar configurar su grupo de aplicaciones web para reciclar procesos de trabajo con frecuencia?

información relacionada