Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Linux
Neste documento, descrevemos como solucionar problemas de bloqueios leves de vCPU. Um bloqueio suave
ocorre quando a vCPU de uma instância de máquina virtual (VM) não consegue executar uma nova tarefa
por mais de 20 segundos. A maioria dos bloqueios leves é causada por bugs no software
de aplicativos.
Bloqueios leves podem fazer com que as VMs não respondam por curtos períodos, interrompam o acesso SSH a elas e acionem tempos limite ou failover de aplicativos. As VMs que estão passando por um soft lockup também podem ter uso da CPU incomumente alto ou baixo, dependendo da causa exata do soft lockup.
Identificar bloqueios parciais
Para identificar se a VM está passando por um soft lockup, faça uma das seguintes ações:
Depois de identificar que um soft lockup está ocorrendo, siga estas etapas de solução de problemas para resolver o problema:
Verifique no site do fornecedor do SO se há erros conhecidos na sua versão do SO. Às vezes, é possível encontrar referências a módulos específicos do kernel no stack trace que sugerem uma função ou operação específica envolvida.
Identifique se o bloqueio parcial se repete com alguma frequência, como
coincidindo com alta carga ou determinadas atividades. Se os bloqueios leves estiverem relacionados a uma carga alta, talvez seja necessário reconfigurar a carga de trabalho, por exemplo, usando uma VM maior ou dividindo a carga em mais VMs.
Verifique se os bloqueios leves estão relacionados a mudanças no ambiente de
execução, como novas implantações de software ou atualizações de imagens do SO.
Se as etapas de solução de problemas anteriores não resolverem o problema,
registre um caso de suporte
e inclua todas as informações coletadas durante a solução de problemas.
Práticas recomendadas para evitar bloqueios leves
Para evitar que suas VMs sofram bloqueios leves, recomendamos implementar as seguintes práticas recomendadas:
Verifique se você tem os componentes redundantes adequados configurados para seu sistema, como clusters de alta disponibilidade, para oferecer um recurso de failover se uma VM específica apresentar um soft lockup prolongado. Para mais informações,
consulte Como projetar sistemas resilientes.
Teste sua carga de trabalho com eventos de manutenção simulados para saber como ela funciona durante a migração em tempo real (se ativada), principalmente em testes de carga.
Se você estiver executando um kernel do Linux ou módulos personalizados na sua VM, teste as novas
mudanças sob carga antes de implantá-las no ambiente de produção.
Confirme se as mudanças personalizadas não impedem que você receba suporte do fornecedor do SO.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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)."]]
