Résoudre les problèmes de blocages logiciels des vCPU
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Linux
Ce document explique comment résoudre les problèmes de blocage logiciel des processeurs virtuels. Un blocage logiciel se produit lorsque le processeur virtuel d'une instance de machine virtuelle (VM) ne parvient pas à exécuter une nouvelle tâche pendant plus de 20 secondes. La plupart des blocages logiciels sont dus à des bugs dans le logiciel de l'application.
Les blocages logiciels peuvent rendre les VM non réactives pendant de courtes périodes, perturber l'accès SSH aux VM et déclencher des délais d'attente ou des basculements d'application. Les VM qui rencontrent un blocage logiciel peuvent également présenter une utilisation du processeur anormalement élevée ou faible, selon la cause exacte du blocage logiciel.
Identifier les verrouillages partiels
Pour déterminer si votre VM est confrontée à un blocage logiciel, procédez comme suit :
Une fois que vous avez identifié qu'un blocage temporaire se produit, essayez les étapes de dépannage suivantes pour résoudre le problème :
Consultez le site de votre fournisseur d'OS pour connaître les erreurs connues avec votre version d'OS. Il peut arriver que vous trouviez des références à des modules de noyau spécifiques dans la trace de la pile, ce qui suggère une fonction ou une opération particulière impliquée.
Déterminez si le blocage temporaire se répète à une certaine fréquence, par exemple en cas de charge élevée ou lors de certaines activités. Si les blocages logiciels sont corrélés à une charge élevée, vous devrez peut-être reconfigurer votre charge de travail, par exemple en utilisant une VM plus grande ou en répartissant la charge sur plusieurs VM.
Vérifiez si les blocages logiciels sont liés à des modifications apportées à votre environnement d'exécution, comme de nouveaux déploiements de logiciels ou des mises à jour d'images d'OS.
Évaluez si des événements de maintenance ont eu lieu au moment du blocage temporaire en examinant les journaux d'audit pour les journaux d'audit des événements système.
Si les étapes de dépannage précédentes n'ont pas permis de résoudre le problème, envoyez une demande d'assistance en incluant toutes les informations que vous avez recueillies lors du dépannage.
Bonnes pratiques pour éviter les blocages temporaires
Pour éviter que vos VM ne subissent des blocages logiciels, nous vous recommandons d'appliquer les bonnes pratiques suivantes :
Assurez-vous d'avoir configuré les composants redondants appropriés pour votre système, tels que les clusters à haute disponibilité, afin de fournir une capacité de basculement si une VM particulière subit un blocage logiciel prolongé. Pour en savoir plus, consultez Concevoir des systèmes résilients.
Testez votre charge de travail avec des événements de maintenance simulés pour découvrir ses performances lors de la migration à chaud (si elle est activée), en particulier lors des tests de charge.
Si vous exécutez un noyau Linux personnalisé ou des modules personnalisés dans votre VM, testez les nouvelles modifications sous charge avant de les déployer dans votre environnement de production.
Vérifiez que vos modifications personnalisées ne vous empêchent pas de recevoir l'assistance de votre fournisseur d'OS.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/04 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 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)."]]
