PSU baratas: cómo ahorrar $20 se convierte en un espectáculo de fuegos artificiales

Por qué las PSU baratas fallan de forma perjudicial

Una fuente de alimentación es un traductor entre el mundo desordenado (la corriente de la pared, la salida de tu UPS, tu generador, el aire acondicionado del vecino)
y el mundo exigente (VRMs de la CPU, raíles de RAM, controladores SSD). “Convierte AC en DC” es como describir un hospital como “un edificio con camas.”

Las PSU baratas no son solo “menos eficientes.” A menudo carecen de características de protección, están hechas con condensadores de peor calidad, disipadores subdimensionados,
etiquetas optimistas y lazos de control que se vuelven inestables bajo transitorios del mundo real. La unidad puede alimentar un escritorio durante una tarde tranquila.
Luego lanzas una compilación, un ZFS scrub, un trabajo de GPU o una tormenta de VM y se convierte en el equivalente eléctrico de un niño manejando una carretilla elevadora.

Lo difícil es que la mala energía no siempre mata las cosas de inmediato. Puede causar:

• Corrupción silenciosa: escrituras en almacenamiento que “tienen éxito” pero quedan mal.
• Heisenbugs: pánicos del kernel y segfaults aleatorios que desaparecen cuando cambias algo no relacionado.
• Envejecimiento de componentes: acortas la vida de discos, VRMs de placa base y NICs por ripple y calor.
• Fallas “solo bajo carga”: estable en idle, inestable cuando está ocupado—justo cuando te importa.

Los $20 que “ahorraste” no se comparan con una PSU mejor. Se comparan con tu tiempo, tu presupuesto de indisponibilidad, la credibilidad de tu SLA y los datos
que no puedes recrear. Si ejecutas producción, la PSU más barata es la que nunca tienes que mencionar.

Un chiste corto, para limpiar el paladar: Una PSU barata es como un póster motivacional—se ve solidaria, pero colapsa bajo presión real.

Lo que las buenas PSU hacen y las baratas a menudo no

Las PSU de calidad tienden a ofrecer comportamiento aburrido y repetible:

• Regulación de voltaje ajustada en rangos de carga, no solo en un punto “amigable para reseñas”.
• Bajo ripple y ruido, para que los VRMs downstream no estén constantemente filtrando basura.
• Respuesta transitoria rápida cuando la carga de CPU/GPU sube de 20% a 90% en milisegundos.
• Circuitos de protección reales: OCP, OVP, UVP, OTP, SCP y preferiblemente un comportamiento de apagado “sin drama”.
• Hold-up time que sobrevive breves caídas de entrada sin reinicios por brownout.
• Calificaciones conservadoras: 750W que realmente pueden dar 750W a temperatura real.

No puedes “RAIDear” una PSU que deja caer raíles o rocía ripple justo en el momento en que el controlador SSD está comprometiendo una tabla de mapeo.
La redundancia ayuda. No deroga la física.

Hechos e historia que importan más que el marketing

Aquí hay hechos concretos y puntos de contexto que explican por qué el mercado de PSU está lleno de trampas. No son trivia; son la razón por la que sigues
viendo las mismas fallas repetirse en empresas y homelabs.

1. 80 PLUS empezó como un programa de eficiencia, no como un sello de calidad.
   La certificación mide principalmente eficiencia en algunos puntos de carga; no garantiza bajo ripple, buenas protecciones o comportamiento seguro en el apagado.
2. El etiquetado de “potencia pico” se ha abusado durante décadas.
   Algunas unidades anuncian un número que pueden entregar brevemente, no de forma continua, y a veces solo a temperaturas internas poco realistas.
3. Los estándares ATX evolucionaron porque los raíles inestables causaban inestabilidad real.
   Los sistemas modernos dependen mucho del rail de 12V, con VRMs de CPU/GPU reductores; los diseños antiguos cuidaban más la distribución de 3.3V/5V.
4. El hold-up time es una característica de fiabilidad oculta.
   Es la capacidad de la PSU para mantener DC estable durante milisegundos después de que cae la entrada AC. Un tiempo de hold-up corto convierte pequeñas caídas en reinicios y resets de disco.
5. Los condensadores electrolíticos envejecen más rápido con calor y corriente de ripple.
   Los condensadores baratos y los diseños más calientes pierden capacitancia, aumentando el ripple con el tiempo, lo que acelera la falla—un bucle de retroalimentación feo.
6. Los diseños regulados por grupo pueden tener problemas con patrones de cross-load modernos.
   Si tu carga es mayoritariamente 12V (común hoy), una PSU group-regulated puede regular mal raíles menores y tener peor respuesta transitoria.
7. Las “protecciones” pueden figurar en la hoja de especificaciones pero estar mal ajustadas.
   Una protección contra sobrecorriente configurada demasiado alta es básicamente decorativa; una protección contra subtensión demasiado baja hace que tu sistema sufra antes de dispararse.
8. Las PSU de servidor popularizaron la redundancia hot-swap por una razón.
   Los centros de datos aprendieron por las malas que la energía es una causa principal de eventos que impactan el servicio, y las PSU hot-swap te permiten arreglarlo sin tiempo de inactividad.

Una cita para mantenerte honesto. Parafraseando a W. Edwards Deming: La calidad se diseña en el proceso; no puedes inspeccionarla después.
Eso es las PSU en una frase. No puedes “testear” para que un diseño malo se vuelva bueno.

Qué es lo que realmente se rompe: modos de fallo en lenguaje claro

1) Ripple y ruido: el veneno lento

El ripple es ruido AC sobrepuesta en la salida DC. Los VRMs y reguladores downstream lo filtran, pero no son compactadores infinitos de basura.
El exceso de ripple aumenta el calor en los VRMs, puede desencadenar comportamientos marginales en la RAM y PCIe, y hace que la electrónica de almacenamiento trabaje más.
La firma de fallo es desesperante: obtienes errores “aleatorios” bajo carga, especialmente en días cálidos.

Piénsalo como alimentar a un maratonista con bebidas energéticas y grava. Seguirá corriendo—por un tiempo.

2) Respuesta transitoria: cuando la carga cambia más rápido que la reacción de la PSU

Las CPU y GPU modernas cambian su consumo extremadamente rápido. Una buena PSU maneja el escalón sin que la salida caiga fuera de especificación o sobrepase.
El lazo de control de una unidad barata puede retrasarse u oscilar. El resultado: breves eventos de undervoltage que causan:

• Reinicios instantáneos (sin apagado limpio)
• Resets de enlace PCIe (la NIC desaparece, NVMe se reinicia)
• Excepciones machine check del kernel
• Flushes de caché de disco que agotan el tiempo

3) Protecciones que no protegen

Una PSU debería apagarse limpiamente cuando las cosas salen de rango. Protecciones faltantes o mal ajustadas convierten una falla manejable en daño colateral.
Las típicas:

• OVP (Over Voltage Protection): evita que “ups, 12V se volvió 14V” mate las placas.
• UVP (Under Voltage Protection): evita el limbo de brownout donde el sistema funciona mal por segundos.
• OCP (Over Current Protection): evita que un cable/rail se convierta en elemento calefactor.
• OTP (Over Temperature Protection): evita que la PSU se cocine y luego falle de forma impredecible.
• SCP (Short Circuit Protection): evita el tipo espectacular de fallo.

4) Corriente de arranque e componentes baratos: el problema “funciona hasta que no”

Las PSU tienen limitación de inrush y circuitos PFC para manejar el arranque. Los diseños baratos pueden estresar componentes al encender, especialmente detrás de ciertos UPS.
Con el tiempo, obtienes fallas al arrancar: el sistema no inicia en frío, inicia tras varios intentos, o solo si apagas/enciendes el interruptor de la PSU.

5) Cableado y conectores: el plástico derretido es una herramienta de diagnóstico que no querías

Incluso si la PSU en sí está “bien”, arneses baratos, cable de calibre fino y conectores mal crimpados se convierten en puntos calientes con alta corriente.
El síntoma: resets intermitentes de GPU, discos SATA que caen, o congelados duros cuando un dispositivo enciende.
Abres la caja y encuentras conectores amarronados. Eso no es “estético.” Es resistencia, calor y fallo inminente.

Segundo chiste corto (y el último): El olor de una PSU fallando es la manera que tiene la naturaleza de decirte que tu ventana de mantenimiento comenzó.

6) Por qué a la gente de almacenamiento le importa tanto

El almacenamiento es donde los pecados de energía se convierten en pecados de datos. La pérdida repentina de energía es una cosa; la corrupción durante una energía inestable es peor porque es silenciosa.
Los sistemas de archivos y las bases de datos tienen estrategias para pérdida de energía. Tienen menos estrategias para “el controlador mintió durante 200 milisegundos.”

Los SSD son particularmente sensibles a eventos de energía a mitad de escritura. Los SSD empresariales a menudo tienen condensadores de protección contra pérdida de energía; las unidades de consumo baratas a menudo no.
Empareja eso con una PSU barata y has construido una máquina de corrupción que solo funciona entre semana.

Tres mini-historias corporativas (anonimizadas, plausibles, técnicamente exactas)

Mini-historia 1: El incidente causado por una suposición equivocada

Una empresa SaaS de tamaño medio amplió un clúster de cómputo usado para trabajos en segundo plano. Compraron un lote de nodos 1U “rentables” de un proveedor secundario.
La hoja de especificaciones parecía bien: potencia adecuada, insignia 80 PLUS y el proveedor prometía “potencia de grado servidor.”

La suposición equivocada fue sutil: asumieron que “de grado servidor” implicaba comportamiento estable en su topología de UPS. Los nodos estaban conectados a un UPS line-interactive
que ocasionalmente cambiaba de modo durante pequeñas fluctuaciones de entrada. La mayoría de servidores no se inmutaron. Este lote sí.

Durante una semana de clima con múltiples pequeñas caídas, el clúster empezó a ver ráfagas de reinicios. Los reinicios no estaban sincronizados, así que parecía software:
tal vez un despliegue defectuoso, tal vez una regresión del kernel, tal vez un problema del scheduler. Los ingenieros lo persiguieron en los logs y no vieron nada consistente.

Luego la cola se atascó. Los timeouts aumentaron. El autoscaling añadió más nodos—más del mismo comportamiento de PSU inestable. Eso convirtió el problema de “algunos reinicios”
en “la plataforma es inestable.” El incidente terminó cuando alguien movió físicamente dos nodos sospechosos a una ruta PDU/UPS diferente y los reinicios cesaron.

El postmortem fue aburrido: reemplazar PSU por modelos conocidos buenos y calificar el equipo de alimentación con una prueba de transición de modo UPS.
La lección no fue “UPS malo.” Fue “no asumas que una etiqueta significa compatibilidad con tu entorno.”

Mini-historia 2: La optimización que salió mal

Un equipo fintech intentó reducir el consumo y el calor en rack. Cambiaron un conjunto de PSU antiguas, ligeramente sobredimensionadas, por unidades más pequeñas “justas”
que prometían mejor eficiencia a carga típica. En papel, era inteligente: menos capacidad desperdiciada, mayor eficiencia, menores facturas.

El problema vino de las cargas reales. Sus sistemas tenían transitorios de potencia pronunciados: ráfagas de CPU, ráfagas de actividad NVMe, aceleración GPU ocasional.
Las PSU más pequeñas trabajaban más cerca de sus límites y tenían peor margen transitorio. Cuando la carga pico llegó, 12V cayó lo suficiente para disparar resets PCIe.

El síntoma no fue “problema de energía.” Fue inestabilidad de almacenamiento: dispositivos NVMe caían y reaparecían, comenzaban reconstrucciones RAID, y la base de datos registraba
errores de IO. Porque las cajas permanecían arriba, la gente sospechó firmware, discos, kernel y backplanes. El equipo reemplazó discos. Luego más discos.

El punto de inflexión fue correlacionar eventos: los logs de reset NVMe se alinearon con advertencias breves de sensores BMC sobre valores mínimos de 12V. Nada catastrófico, solo suficiente.
Volver a PSU de mayor calidad con mejor respuesta transitoria eliminó los resets. La factura eléctrica subió un poco; la tasa de incidentes bajó mucho.

La lección: “justo al tamaño” no es lo mismo que “bien diseñado.” El margen no es desperdicio; es margen de estabilidad.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Un grupo de TI empresarial ejecutaba un clúster de virtualización privado. Nada sofisticado. Eran disciplinados en dos cosas: redundancia de PSU y mantenimiento trimestral.
Cada host tenía PSU dobles hot-swap alimentadas por PDUs separadas, y el equipo probaba rutinariamente el failover tirando una PSU bajo carga durante ventanas planificadas.

Una tarde, un breaker de PDU comenzó a dispararse intermitentemente. No fue un evento en todo el datacenter—solo una alimentación con fallos. Mitad de los racks en esa alimentación
vieron breves caídas de entrada. En muchos entornos, eso se convierte en un corte en cascada mientras los nodos se reinician y las cargas se estremecen.

Aquí, se convirtió en un ticket. Los servidores permanecieron arriba con la alimentación alterna de la otra PSU. El sistema de monitorización alertó sobre “redundancia PSU perdida” y “eventos de voltaje de entrada”
pero las VM no lo notaron. No hubo corrupción de almacenamiento. No split-brain en el clúster. No recuperación heroica a medianoche.

Porque habían practicado el procedimiento, la respuesta fue tranquila: aislar la alimentación PDU defectuosa, desplazar la carga, llamar a facilities y cambiar un módulo de breaker.
El postmortem fue corto. Las acciones fueron en su mayoría: “seguir haciendo lo que hacemos.”

La lección: la fiabilidad suele ser una colección de hábitos aburridos ejecutados de forma consistente.

Guía de diagnóstico rápido (primero/segundo/tercero)

Cuando sospeches de una PSU, necesitas velocidad y un plan. No caigas en la trampa de pasar seis horas demostrando una hipótesis que puedes probar en veinte minutos.
Esta guía está diseñada para la realidad del on-call.

Primero: clasifica la falla y protege los datos

• ¿Se está reiniciando el sistema bruscamente? Si sí, trátalo como energía inestable. Desactiva caches de escritura donde corresponda, pausa trabajos riesgosos (scrubs, rebuilds) y haz snapshots de lo que puedas.
• ¿Huele/está caliente/ruidoso? Si hay olor eléctrico, sonidos de arco o daño visible, apaga de forma segura y deja de “probar”.
• ¿Está aislado o es sistémico? Un host vs varios hosts en la misma PDU apunta a soluciones diferentes.

Segundo: correlaciona logs con sensores y carga

• Revisa logs del kernel por machine checks, resets NVMe, resets de enlace SATA y eventos ACPI.
• Revisa historial de sensores BMC/IPMI por eventos min/max de 12V/5V y estado de PSU.
• Comprueba si las fallas coinciden con picos de CPU/GPU, scrubs de disco o subidas de ventiladores (calor).

Tercero: reduce variables con un swap decisivo o aislamiento

• Si tienes una PSU conocida buena, cámbiala. No “observes” durante días.
• Si hay PSU dual, quita una PSU a la vez bajo carga y mira si cambia el comportamiento.
• Mueve el host a otro circuito/PDU temporalmente para descartar la alimentación upstream.

El cuello de botella en el diagnóstico de PSU suele ser la vacilación humana. Cambia, aísla y mide. No haces filosofía; haces operaciones.

Tareas prácticas: comandos, salidas y decisiones

Estas son comprobaciones prácticas que puedes ejecutar en servidores Linux. Ninguna de ellas “prueba” por sí sola que la PSU está mala.
Juntas te permiten construir un caso sólido rápidamente y evitar reemplazar piezas al azar por frustración.

Task 1: Check for abrupt reboots (no clean shutdown)

cr0x@server:~$ last -x | head -n 12
reboot   system boot  6.8.0-41-generic Mon Jan 22 09:14   still running
shutdown system down  6.8.0-41-generic Mon Jan 22 08:57 - 09:13  (00:16)
reboot   system boot  6.8.0-41-generic Mon Jan 22 08:12 - 08:57  (00:45)
reboot   system boot  6.8.0-41-generic Mon Jan 22 07:38 - 08:12  (00:34)
shutdown system down  6.8.0-41-generic Mon Jan 22 07:35 - 07:38  (00:02)

Qué significa: Entradas “reboot” sin un “shutdown” precedente en el momento adecuado indican un reinicio duro/caída de energía.

Decisión: Tratar como potencial inestabilidad de energía. Prioriza comprobaciones de PSU/UPS/PDU sobre la depuración de aplicaciones.

Task 2: Look for kernel power-related events and machine checks

cr0x@server:~$ journalctl -k -b -1 | egrep -i "mce|machine check|watchdog|reset|nvme|ata|pcie|EDAC" | tail -n 30
Jan 22 08:11:58 server kernel: mce: [Hardware Error]: CPU 0: Machine Check: 0 Bank 5: b200000000070005
Jan 22 08:11:58 server kernel: mce: [Hardware Error]: TSC 0 ADDR fef1c140 MISC d012000100000000
Jan 22 08:11:59 server kernel: nvme nvme0: controller is down; will reset: CSTS=0x1, PCI_STATUS=0x10
Jan 22 08:12:00 server kernel: nvme nvme0: reset controller
Jan 22 08:12:03 server kernel: ata3: SATA link down (SStatus 0 SControl 300)

Qué significa: MCEs más resets de enlace de almacenamiento son territorio clásico de “energía o placa”, especialmente si aparecen bajo carga.

Decisión: Revisa raíles de PSU vía sensores BMC; considera swap inmediato si se correlaciona con reinicios.

Task 3: Check BMC sensors for voltage min/max and PSU status

cr0x@server:~$ ipmitool sdr type Voltage
12V         | 11.71 Volts      | ok
5V          | 4.92 Volts       | ok
3.3V        | 3.28 Volts       | ok
VBAT        | 3.02 Volts       | ok

Qué significa: “ok” no es toda la historia; necesitas historial min/max si está disponible. Aun así, una lectura de 12V cerca del umbral bajo es sospechosa.

Decisión: Si los valores se desplazan bajo carga o coquetean con umbrales, planifica un swap y reduce la carga pico hasta solucionarlo.

Task 4: Get detailed sensor thresholds (if BMC exposes them)

cr0x@server:~$ ipmitool sensor get 12V
Locating sensor record...
Sensor ID              : 12V (0x30)
Entity ID             : 7.1
Sensor Type (Voltage) : Voltage
Sensor Reading        : 11.71 (+/- 0.00) Volts
Lower Non-Recoverable : 10.80
Lower Critical        : 11.00
Lower Non-Critical    : 11.20
Upper Non-Critical    : 12.80
Upper Critical        : 13.00
Upper Non-Recoverable : 13.20

Qué significa: 11.71V está por encima de LNC, pero no con gran margen. Bajo carga transitoria puede caer por debajo de 11.2V brevemente.

Decisión: Si la plataforma se reinicia o los dispositivos caen, trata esto como evidencia corroborante y cambia la PSU o prueba con otra alimentación.

Task 5: Identify PSU model and redundancy (where supported)

cr0x@server:~$ ipmitool fru | egrep -i "Power Supply|PSU|Part Number|Product"
Product Name          : Power Supply 1
Part Number           : PWS-920P-SQ
Product Name          : Power Supply 2
Part Number           : PWS-920P-SQ

Qué significa: Confirma qué hardware tienes realmente, no lo que procurement cree que compró.

Decisión: Si estás solucionando una flota, agrupa incidentes por número de parte de PSU y lote.

Task 6: Detect PSU-related events in system event log (SEL)

cr0x@server:~$ ipmitool sel list | tail -n 10
1a3c | 01/22/2026 | 08:11:57 | Power Supply PS1 | Power Supply AC lost | Asserted
1a3d | 01/22/2026 | 08:11:58 | Power Supply PS1 | Failure detected | Asserted
1a3e | 01/22/2026 | 08:12:04 | Power Supply PS1 | Power Supply AC lost | Deasserted
1a3f | 01/22/2026 | 08:12:05 | Power Supply PS1 | Failure detected | Deasserted

Qué significa: El BMC vio que la PSU perdió entrada AC o falló. Eso está cerca de ser una evidencia concluyente.

Decisión: Reemplaza PS1 e inspecciona la alimentación upstream (cable, toma PDU, breaker).

Task 7: Verify upstream power quality signals from a UPS (if connected via USB/NUT)

cr0x@server:~$ upsc myups@localhost | egrep "input\.voltage|input\.frequency|ups\.status|ups\.load|battery\.charge"
input.voltage: 228.0
input.frequency: 50.0
ups.status: OL
ups.load: 41
battery.charge: 100

Qué significa: OL significa “on line.” Si ves transiciones frecuentes OL/OB, tu PSU puede reaccionar mal a eventos de transferencia.

Decisión: Si las transiciones se correlacionan con reinicios, prueba con un modo de UPS diferente o una PSU de mayor calidad con mejor hold-up time.

Task 8: Check for PCIe device resets (common with undervoltage transients)

cr0x@server:~$ journalctl -k | egrep -i "pcie.*error|AER|link down|link reset|Surprise Down" | tail -n 25
Jan 22 08:11:59 server kernel: pcieport 0000:00:1c.0: AER: Corrected error received: 0000:00:1c.0
Jan 22 08:11:59 server kernel: pcieport 0000:00:1c.0: PCIe Bus Error: severity=Corrected, type=Physical Layer
Jan 22 08:12:00 server kernel: pcieport 0000:00:1c.0: device [8086:a110] error status/mask=00000001/00002000

Qué significa: Errores corregidos de capa física pueden ser integridad de señal, pero si aumentan con la carga y coinciden con resets, la energía es sospechosa.

Decisión: Combina con datos de sensores de voltaje; si ambos apuntan en la misma dirección, deja de culpar al firmware primero.

Task 9: Check SATA/NVMe link stability

cr0x@server:~$ dmesg -T | egrep -i "ata[0-9]|link down|hard resetting link|nvme.*reset" | tail -n 30
[Mon Jan 22 08:12:03 2026] ata3: SATA link down (SStatus 0 SControl 300)
[Mon Jan 22 08:12:03 2026] ata3: hard resetting link
[Mon Jan 22 08:12:05 2026] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[Mon Jan 22 08:12:06 2026] nvme nvme0: controller is down; will reset: CSTS=0x1

Qué significa: Los enlaces de almacenamiento no deberían oscilar en un servidor sano. Las caídas de potencia pueden hacer que los controladores se reinicien.

Decisión: Si ves resets de enlaces más reinicios duros, prioriza la inspección de PSU y cableado de inmediato.

Task 10: Stress CPU to reproduce transient load issues (controlled test)

cr0x@server:~$ sudo apt-get update -qq && sudo apt-get install -y stress-ng
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  stress-ng
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Setting up stress-ng (0.17.12-1ubuntu0.1) ...

cr0x@server:~$ sudo stress-ng --cpu 0 --cpu-method matrixprod --timeout 120s --metrics-brief
stress-ng: info:  [21412] dispatching hogs: 32 cpu
stress-ng: metrc: [21412] stressor       bogo ops real time  usr time  sys time   bogo ops/s
stress-ng: metrc: [21412] cpu               5231    120.00  3790.11     0.31        43.59
stress-ng: info:  [21412] successful run completed in 120.02s

Qué significa: Si esto dispara consistentemente reinicios o resets de dispositivos, estás ante entrega de potencia, térmicos o VRMs de placa.

Decisión: Si aparecen fallas con esta prueba, cambia la PSU y vuelve a probar antes de culpar al kernel/aplicación.

Task 11: Monitor voltages and temperatures during load (lm-sensors)

cr0x@server:~$ sudo apt-get install -y lm-sensors
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  lm-sensors
Setting up lm-sensors (1:3.6.0-7.1ubuntu1) ...

cr0x@server:~$ sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +71.0°C  (high = +90.0°C, crit = +100.0°C)
Core 0:        +67.0°C  (high = +90.0°C, crit = +100.0°C)

nct6798-isa-0a20
Adapter: ISA adapter
in0:          +1.02 V
in1:          +1.81 V
in2:          +12.00 V
in3:          +5.02 V
in4:          +3.33 V
fan1:        1200 RPM

Qué significa: Estas lecturas pueden ser aproximadas, pero buscas deriva o caídas súbitas bajo carga.

Decisión: Si 12V/5V se desploman significativamente durante el estrés, para—tu ruta PSU/VRM es inestable.

Task 12: Check memory errors (power can masquerade as RAM problems)

cr0x@server:~$ journalctl -k | egrep -i "EDAC|ecc|memory error" | tail -n 20
Jan 22 08:11:58 server kernel: EDAC MC0: 1 CE memory read error on CPU_SrcID#0_Ha#0_Chan#1_DIMM#0
Jan 22 08:11:58 server kernel: EDAC sbridge MC0: HANDLING MCE MEMORY ERROR

Qué significa: Errores corregibles (CE) podrían ser degradación real de DIMM, pero ráfagas que se alinean con eventos de energía son sospechosas.

Decisión: Si los errores ECC aumentan durante eventos transitorios de PSU, arregla la energía primero y luego reevalúa las DIMMs.

Task 13: Check filesystem and block layer for IO errors after events

cr0x@server:~$ journalctl -p err..alert -b | egrep -i "I/O error|EXT4-fs error|XFS.*CORRUPT|blk_update_request|Buffer I/O" | tail -n 30
Jan 22 08:12:01 server kernel: blk_update_request: I/O error, dev nvme0n1, sector 428032, op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0
Jan 22 08:12:01 server kernel: Buffer I/O error on dev nvme0n1p2, logical block 53504, lost async page write

Qué significa: IO errors tras un reset pueden ser reacción en cadena de resets de dispositivos, o el propio disco. La inestabilidad de potencia aumenta ambas probabilidades.

Decisión: No empieces a reemplazar discos a ciegas. Estabiliza la energía y luego ejecuta SMART/self-tests.

Task 14: Check SMART and error logs (to separate “bad drive” from “bad power”)

cr0x@server:~$ sudo smartctl -a /dev/sda | egrep -i "Reallocated_Sector_Ct|Current_Pending_Sector|UDMA_CRC_Error_Count|Power_Cycle_Count|Power-Off_Retract_Count"
Reallocated_Sector_Ct     0
Current_Pending_Sector    0
UDMA_CRC_Error_Count      19
Power_Cycle_Count         142
Power-Off_Retract_Count   27

Qué significa: UDMA CRC errors suelen indicar problemas de cableado o señal. Un “Power-Off Retract” en aumento apunta a pérdida abrupta de energía.

Decisión: Si los CRC aumentan, inspecciona/reemplaza cables SATA y arnés de alimentación; si aumentan eventos de power-off, arregla la ruta PSU/UPS.

Task 15: Inspect and verify CPU frequency throttling (power/thermal interactions)

cr0x@server:~$ sudo apt-get install -y linux-tools-common linux-tools-generic
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  linux-tools-common linux-tools-6.8.0-41-generic linux-tools-generic
Setting up linux-tools-common (6.8.0-41.41) ...
Setting up linux-tools-generic (6.8.0-41.41) ...

cr0x@server:~$ sudo turbostat --Summary --quiet --show Busy%,Bzy_MHz,TSC_MHz,PkgTmp --interval 1 --num_iterations 5
Busy%   Bzy_MHz  TSC_MHz  PkgTmp
12.34   2101     2200     74
89.02   3298     2200     89
91.11   2980     2200     94
88.50   2750     2200     96
90.20   2605     2200     97

Qué significa: Caída de Bzy_MHz con alto Busy% y aumento de temperatura del paquete sugiere throttling. El throttling puede cambiar los patrones de carga y exponer debilidad de la PSU.

Decisión: Arregla primero la refrigeración si estás cerca de límites térmicos; luego evalúa la estabilidad de la PSU bajo condiciones térmicas esperadas.

Task 16: If dual-PSU, test redundancy under load (controlled)

cr0x@server:~$ sudo stress-ng --cpu 0 --timeout 60s --metrics-brief
stress-ng: info:  [21901] dispatching hogs: 32 cpu
stress-ng: info:  [21901] successful run completed in 60.01s

cr0x@server:~$ ipmitool sel clear
Clearing SEL.  Please allow a few seconds to erase.

cr0x@server:~$ ipmitool sel list
SEL has no entries

Qué significa: Borrar SEL te permite ver nuevos eventos de redundancia PSU durante tu prueba controlada (mientras físicamente tiras de una PSU).

Decisión: Si quitar la PSU A causa inestabilidad pero quitar la PSU B no, PSUA (o su alimentación/cable) es sospechosa.

Nota: tus manos no son un comando. Pero forman parte de la herramienta de diagnóstico. Si haces pruebas físicas, hazlas en una ventana de mantenimiento, con supervisión
y con pasos claros de rollback.

Errores comunes: síntoma → causa raíz → solución

1) “Reinicios aleatorios, sin logs” → brownouts/hold-up time insuficiente → prueba y swap

Síntoma: El sistema reinicia sin apagado limpio; los logs muestran un hueco.

Causa raíz: La salida de la PSU cae fuera de tolerancia durante una carga transitoria o una caída de AC; tiempo de hold-up demasiado corto.

Solución: Cambiar a una PSU conocida buena; revisar eventos de transferencia del UPS; asegurar margen y calidad adecuados en la PSU.

2) “NVMe desaparece, luego vuelve” → undervoltage transitorio → mejorar respuesta transitoria de la PSU

Síntoma: Bucles de reset NVMe, errores IO, disparos de rebuild RAID.

Causa raíz: Resets de dispositivos PCIe causados por breves caídas de 12V o rail ruidoso.

Solución: Reemplazar PSU por una con mejor comportamiento transitorio; reducir picos de carga; verificar cableado y conectores del backplane.

3) “Errores CRC SATA en aumento” → cable malo o arnés de alimentación deficiente → reemplazar el cable correcto

Síntoma: SMART muestra UDMA_CRC_Error_Count en aumento; los discos caen bajo carga.

Causa raíz: Problema de cableado de señal (cable SATA, backplane), a veces empeorado por ripple y calentamiento de conectores.

Solución: Reemplazar cables de datos SATA/backplane; inspeccionar conectores de alimentación amarronados; asegurar conexiones limpias y firmes.

4) “Errores ECC corregibles aumentan solo durante IO intenso” → ruido de energía → arreglar la energía primero

Síntoma: Ráfaga de errores de memoria corregibles durante scrubs/backups.

Causa raíz: Ruido en la entrega de energía que causa tiempos marginales; puede presentarse como inestabilidad de RAM.

Solución: Validar raíles de PSU y cambiar PSU antes de reemplazar DIMMs; volver a probar después de la corrección de energía.

5) “Solo falla cuando está caliente” → envejecimiento de condensadores y derating térmico → mejorar flujo de aire y PSU de calidad

Síntoma: Estable en invierno o con la tapa abierta; falla con ambientes de verano o curvas de ventilador altas.

Causa raíz: La temperatura interna de la PSU barata aumenta; los condensadores pierden capacitancia efectiva; la regulación empeora.

Solución: Mejorar el flujo de aire del chasis, limpiar el polvo y reemplazar la PSU por un diseño con mejor tolerancia térmica; evitar operar cerca del máximo.

6) “El ventilador de la PSU grita, luego se para, luego el servidor muere” → fallo de ventilador/mal comportamiento de OTP → reemplazar inmediatamente

Síntoma: Comportamiento errático del ventilador de la PSU; apagados intermitentes.

Causa raíz: Falla de rodamientos del ventilador o control térmico pobre; la protección por temperatura puede dispararse tarde.

Solución: Reemplazar la PSU. No “solo reemplaces el ventilador” en producción salvo que te guste arriesgar el café.

7) “Reemplazamos discos y sigue pasando” → persiguiendo a la víctima, no al atacante → detener y re-baselinear

Síntoma: Múltiples intercambios de componentes no arreglan reinicios y errores IO.

Causa raíz: PSU o alimentación upstream causando errores en cascada a través de dispositivos.

Solución: Re-baseline: correlacionar resets con sensores de energía; hacer swap de PSU conocida buena; verificar comportamiento PDU/UPS.

8) “La marca conocida significa seguro” → variación por modelo/plataforma → calificar la unidad exacta

Síntoma: “Pero es una marca reputada” mientras persisten problemas.

Causa raíz: Las marcas subcontratan; la calidad varía por plataforma, revisión y OEM.

Solución: Seleccionar PSU por rendimiento eléctrico verificado y protecciones, no por logo; estandarizar en modelos conocidos buenos.

Listas de verificación / plan paso a paso

Lista de compra: cómo no comprar problemas

• Compra por comportamiento eléctrico, no por vatios. Busca validación independiente de ripple, respuesta transitoria, protecciones y hold-up time.
• Planifica margen. Apunta a que la carga típica esté alrededor del 40–60% de la potencia nominal para eficiencia y margen transitorio (los números exactos dependen de la plataforma, pero “cerca del máximo” es pedir problemas).
• Prefiere diseños DC-DC modernos para raíles menores si construyes sistemas ATX, y PSU de servidor reputadas para equipo en rack.
• Revisa calidad de conectores y calibre del arnés. Especialmente para GPUs y nodos con muchas unidades de almacenamiento.
• Estandariza modelos. Menos SKUs de PSU significa menos desconocidos y swaps más rápidos.
• Decide tu estrategia de redundancia desde el principio. Dual-PSU con alimentaciones separadas si la disponibilidad importa; PSU única más repuesto frío si no.

Lista de construcción: detalles de instalación que previenen cortes

• Usa PDUs/circuitos separados para PSUs redundantes. “Dos PSUs en la misma regleta” es teatro.
• Etiqueta el mapeo PSU→PDU. Los humanos depuran más rápido cuando el mundo físico está documentado.
• No sobrecargues un único racimo de cables. Evita curvas cerradas y tensión en conectores.
• Para servidores de almacenamiento, verifica la distribución de energía de los discos. Escalonar spin-up cuando sea posible.
• Configura monitorización para pérdida de redundancia PSU, eventos de voltaje y reinicios inesperados.

Lista operativa: cuando un host empieza a comportarse como embrujado

1. Congela escrituras riesgosas: pausa scrubs/rebuilds/backfills si el sistema está flapeando.
2. Clasifica la falla: reset duro vs reinicio gracioso vs resets de dispositivo.
3. Extrae logs: last -x, journalctl -k, SMART, BMC SEL.
4. Correlaciona con la carga: ¿hubo un pico de trabajo, backup o tormenta de compilaciones?
5. Revisa upstream: transiciones de estado del UPS, alertas PDU, disparos de breakers.
6. Cambia por una PSU conocida buena (o intercambia la posición de PSUs en chasis dual).
7. Repite la prueba de estrés controlada y confirma estabilidad antes de cerrar.
8. Escribe una nota breve del incidente: qué viste, qué cambiaste y qué reemplazaste.

Lista de diseño: especificaciones para almacenamiento y virtualización

• ZFS/RAID arrays: prefiere energía estable y UPS; evita comportamiento de brownout inestable que cause resets repetidos de dispositivos.
• Nodos con muchas SSD: considera unidades con protección contra pérdida de energía; PSU baratas más SSD de consumo es una combinación peligrosa.
• Nodos GPU: prioriza cableado, calidad de conectores y respuesta transitoria; las GPUs tienen cargas muy espigadas.
• Hosts de virtualización: dual PSUs, alimentaciones separadas y alertas por pérdida de redundancia son innegociables si te importa la disponibilidad.

Preguntas frecuentes

1) ¿Es 80 PLUS Gold suficiente para garantizar una buena PSU?

No. Mayormente te indica eficiencia en puntos de carga específicos. Una PSU puede ser eficiente y aun así tener ripple mediocre, mala respuesta transitoria
o protecciones mal ajustadas. Trata 80 PLUS como “un dato más”, no como un certificado de seguridad.

2) ¿Cuál es el síntoma real más común de una PSU mala?

Reinicios duros bajo carga. Especialmente cuando se combinan con resets de enlaces de almacenamiento (SATA/NVMe) o errores AER de PCIe.

3) ¿Puede una PSU barata causar corrupción de datos sin reiniciar?

Sí, aunque es más difícil de probar. El ripple y las caídas transitorias pueden desestabilizar controladores y rutas de memoria de formas que crean escrituras erróneas o
inconsistencias de metadata. Los sistemas de archivos y bases de datos son robustos, pero no son mágicos.

4) Si mi sistema arranca y corre juegos, ¿por qué no correría una carga de servidor?

Los servidores suelen ejecutar IO sostenido alto y CPU estable por horas, además de ráfagas simultáneas (scrubs, backups, compactaciones).
Las pruebas de consumo “funciona en mi escritorio” no cubren esos patrones ni el entorno térmico de un rack.

5) ¿Cuánto margen debería dejar al dimensionar una PSU?

Suficiente para que la operación normal no viva cerca del borde. Un objetivo práctico es mantener la carga típica en 40–60% y asegurar que los picos
queden cómodamente por debajo de la potencia continua de la PSU. El margen exacto depende de transitorios (los nodos GPU necesitan más).

6) ¿Los cables modulares son intercambiables entre marcas de PSU?

Normalmente no, y “normalmente” no es una estrategia de riesgo. Los pinouts difieren incluso dentro de la misma marca entre líneas de producto.
Mezclar cables puede matar instantáneamente discos y placas. Usa solo los cables indicados para ese modelo exacto de PSU.

7) ¿Un UPS hace que las PSU baratas sean seguras?

Un UPS ayuda con apagones y algunas anomalías, pero no arregla mala respuesta transitoria o alto ripple.
Además, algunas PSU se comportan mal durante eventos de transferencia de UPS. Prueba tu pareja exacta.

8) ¿Qué hay de las PSU redundantes—puedo usar dos baratas y estar bien?

La redundancia reduce el downtime por falla de una PSU, pero no garantiza energía limpia ni buen comportamiento bajo carga.
Dos PSU malas pueden seguir produciendo inestabilidad, y una unidad fallando puede estresar a la otra o inyectar ruido antes de morir.

9) ¿Cómo distinguir si el problema es la PSU o los VRM de la placa base?

A menudo no puedes saber limpiamente sin intercambiar. Pero los patrones ayudan: los problemas de PSU se correlacionan con eventos AC/SEL de la PSU, resets múltiples de dispositivos a la vez,
y cambios cuando mueves circuitos. Los problemas de VRM pueden correlacionarse con carga específica de CPU y temperatura y persistir entre PSUs.
En ops, primero cambias el componente más barato/rápido de intercambiar—a menudo la PSU.

10) ¿Cuál es la actualización más segura para una caja de almacenamiento en un homelab?

Compra una PSU conocida buena con protecciones fuertes y margen decente, pon el sistema en un UPS y evita mezclar cables modulares.
Si manejas datos importantes, prioriza estabilidad sobre estética y funciones RGB.

Siguientes pasos que puedes hacer esta semana

Si ejecutas sistemas de producción, trata las PSU como los neumáticos de una flota: no compras las más baratas y esperas que tus conductores mejoren en física.
La calidad de la energía es fundamental. Todo lo demás depende de ella.

Acciones prácticas

• Inventario de PSUs (modelo y número de parte) en tu flota usando BMC donde sea posible, e identifica unidades desconocidas/de baja confianza.
• Elige uno o dos modelos de PSU estandarizados y probados para cada clase de chasis (almacenamiento, cómputo, GPU) y deja de improvisar por pedido de compra.
• Implementa alertas para reinicios inesperados, “redundancia PSU perdida” y eventos de umbrales de voltaje desde BMC.
• Realiza una prueba de estrés controlada en hardware nuevo durante el burn-in y observa señales de reset PSU/PCIe/almacenamiento.
• Mantén repuestos fríos de los modelos estandarizados. El incidente más rápido es el que terminas con un swap y una nota.
• Para servicios críticos, cambia a dual-PSU con alimentaciones separadas y prueba el failover trimestralmente—aburrido, repetible, efectivo.

Si aún te tienta la PSU de oferta, hazte otra pregunta: “¿Cuál es mi tarifa por hora durante un outage?”
De repente, los $20 de ahorro empiezan a parecer un préstamo con interés agresivo.