Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Linux
En este documento, se describe cómo solucionar problemas de bloqueos temporales de CPU virtuales. Un bloqueo temporal ocurre cuando la CPU virtual de una instancia de máquina virtual (VM) no puede ejecutar una tarea nueva durante más de 20 segundos. La mayoría de los bloqueos temporales se deben a errores en el software de la aplicación.
Los bloqueos temporales pueden hacer que las VMs no respondan durante períodos breves, interrumpir el acceso SSH a las VMs y activar tiempos de espera o conmutaciones por error de las aplicaciones. Las VMs que experimentan un bloqueo temporal también pueden tener un uso de CPU inusualmente alto o bajo, según la causa exacta del bloqueo temporal.
Cómo identificar bloqueos parciales
Para identificar si tu VM experimenta un bloqueo temporal, haz una de las siguientes acciones:
Después de identificar que se produce un bloqueo temporal, prueba los siguientes pasos para solucionar el problema:
Consulta el sitio del proveedor de tu SO para conocer los errores conocidos de tu versión del SO. A veces, es posible que encuentres referencias a módulos específicos del kernel en el registro de seguimiento de pila que sugieran una función u operación en particular involucrada.
Identifica si el bloqueo temporal se repite con alguna frecuencia, por ejemplo, si coincide con una carga alta o ciertas actividades. Si los bloqueos temporales se correlacionan con una carga alta, es posible que debas reconfigurar tu carga de trabajo, por ejemplo, usando una VM más grande o dividiendo la carga en más VMs.
Comprueba si los bloqueos temporales se correlacionan con algún cambio en tu entorno de ejecución, como implementaciones de software nuevas o actualizaciones de imagen de SO.
Evalúa si se produjeron eventos de mantenimiento cerca del momento del bloqueo temporal. Para ello, revisa los registros de auditoría de los registros de auditoría de eventos del sistema.
Si los pasos anteriores para solucionar problemas no resolvieron el problema, presenta un caso de asistencia al cliente y proporciona toda la información que recopilaste durante la solución de problemas.
Prácticas recomendadas para evitar bloqueos temporales
Para evitar que tus VMs experimenten bloqueos temporales, te recomendamos que implementes las siguientes prácticas recomendadas:
Asegúrate de tener configurados los componentes redundantes adecuados para tu sistema, como los clústeres de alta disponibilidad, para proporcionar una capacidad de conmutación por error si una VM en particular experimenta un bloqueo temporal prolongado. Para obtener más información, consulta Diseña sistemas resilientes.
Prueba tu carga de trabajo con eventos de mantenimiento simulados para saber cómo se comporta durante la migración en vivo (si está habilitada), en especial durante las pruebas de carga.
Si ejecutas un kernel de Linux personalizado o módulos personalizados en tu VM, prueba los cambios nuevos bajo carga antes de implementarlos en tu entorno de producción.
Confirma que los cambios personalizados no te impidan recibir asistencia del proveedor del SO.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-09-04 (UTC)"],[[["\u003cp\u003eSoft lockups occur when a VM's vCPU cannot run a new task for over 20 seconds, often due to application software bugs.\u003c/p\u003e\n"],["\u003cp\u003eSoft lockups can cause VMs to become unresponsive, disrupt SSH access, and trigger application timeouts or failovers.\u003c/p\u003e\n"],["\u003cp\u003eSoft lockups can be identified by reviewing serial port output or operating system logs for a soft lockup stack trace, such as \u003ccode\u003ewatchdog: BUG: soft lockup - CPU#3 stuck for 22s!\u003c/code\u003e.\u003c/p\u003e\n"],["\u003cp\u003eTroubleshooting soft lockups involves checking for OS vendor known issues, identifying patterns with high load or environment changes, and evaluating maintenance events.\u003c/p\u003e\n"],["\u003cp\u003ePreventive measures include using redundant components, compute-optimized machine families for intense workloads, testing with simulated maintenance events, and keeping the OS up to date.\u003c/p\u003e\n"]]],[],null,["# Troubleshooting vCPU soft lockups\n\nLinux\n\n*** ** * ** ***\n\nThis document describes how to troubleshoot vCPU soft lockups. A *soft lockup*\noccurs when a virtual machine (VM) instance's vCPU is unable to run a new task\nfor more than 20 seconds. Most soft lockups are caused by bugs in application\nsoftware.\n\nSoft lockups can cause VMs to become unresponsive for short periods of time,\ndisrupt SSH access to VMs, and trigger application timeouts or failover. VMs\nthat are experiencing a soft lockup might also have unusually high or\nunusually low CPU utilization, depending on the exact cause of the soft lockup.\n\nIdentify soft lockups\n---------------------\n\nTo identify whether your VM is experiencing a soft lockup, do one of the\nfollowing:\n\n- If you previously enabled [serial port output logging](/compute/docs/troubleshooting/viewing-serial-port-output#enable-stackdriver) for your VM, [review serial port output](/compute/docs/troubleshooting/viewing-serial-port-output#viewing_serial_port_output) for a soft lockup stack trace.\n- Review your VM's operating system logs (`/var/log/messages`) for a soft lockup stack trace.\n\n**Example soft lockup stack trace** \n\n```\nwatchdog: BUG: soft lockup - CPU#3 stuck for 22s!\n```\n\nTo detect future soft lockups, you can do the following:\n\n1. [Enable serial port output logging](/compute/docs/troubleshooting/viewing-serial-port-output#enable-stackdriver).\n\n2. [Create a log-based alerting policy](/logging/docs/alerting/log-based-alerts#lba-definition)\n for the following log:\n\n ```\n resource.type=\"gce_instance\" log_id(\"serialconsole.googleapis.com/serial_port_1_output\") textPayload=~\"watchdog.*lockup\"\n ```\n | **Note:** When you test the query, it is likely that no logs appear. This is expected behavior.\n\nTroubleshoot soft lockups\n-------------------------\n\nAfter you've identified that a soft lockup is occurring, try the following\ntroubleshooting steps to resolve the issue:\n\n1. Check your OS vendor's site for known errors with your OS version. Sometimes you might find reference to specific kernel modules in the stack trace that suggests a particular function or operation that is involved.\n2. Identify whether the soft lockup repeats with any frequency, such as coinciding with high load or certain activities. If the soft lockups correlate with high load, you might need to reconfigure your workload, for example by using a larger VM or splitting the load across more VMs.\n3. Check if the soft lockups correlate with any changes to your runtime environment such as new software deployments or OS image updates.\n4. Evaluate whether any [maintenance events](/compute/docs/instances/host-maintenance-overview#maintenanceevents) have taken place around the time of the soft lockup, by reviewing [audit logs](/compute/docs/logging/audit-logging#viewing_logs) for system event audit logs.\n\nIf the proceeding troubleshooting steps didn't resolve the issue,\n[file a support case](/support/docs/customer-care-procedures#create_a_support_case)\nand include all of the information you gathered from troubleshooting.\n\nBest practices to avoid soft lockups\n------------------------------------\n\nTo help prevent your VMs from experiencing soft lockups, we recommend\nimplementing the following best practices:\n\n- Ensure that you have appropriate redundant components configured for your system, such as high availability clusters, to provide a failover capability if a particular VM experiences a prolonged soft lockup. For more information, see [Designing resilient systems](/compute/docs/tutorials/robustsystems).\n- For compute-intensive workloads, consider using [compute-optimized machine families](/compute/docs/compute-optimized-machines).\n- Test your workload with simulated [maintenance events](/compute/docs/instances/host-maintenance-overview#maintenanceevents) to learn how your workload performs during live migration (if enabled), particularly under load testing.\n- If you're running a custom Linux Kernel or custom modules in your VM, test new changes under load before deploying them to your production environment. Confirm that your custom changes don't disqualify you from receiving support from your OS vendor.\n- Keep your operating system up to date. For more information, see [Operating system details](/compute/docs/images/os-details)."]]
