When dealing with Microsoft software, one often encounters bloating. For instance, with mere three extensions active in VS Code, the .vscode folder on my remote server houses files that are over 300MB. Countless vscode-server processes run on my remote Ubuntu server, even when not actively using VS Code. Although these processes don’t usually require significant resources, there are times they take up a lot of CPU resources making the server almost unusable.
VS Code consumes many CPU resources
This is not an isolated issue as many people have reported it across various forums. Numerous unsuccessful Google searches later, I finally found a solution in a script. The script shared in this post resolved the issue for me and it is compatible with any extension that VS Code installs on the remote system.
In my situation, the Microsoft extensions Remote – SSH (ms-vscode-remote.remote-ssh) and Remote Explorer (ms-vscode.remote-explorer) are causing high CPU usage. I am uncertain which of the two is the culprit, but my assumption is Remote – SSH.
To be fair, I really like the Remote – SSH extension because it can access the SSH configuration file on my Mac. This means that I can use all the SSH remote hosts that I configured for iTerm2 with Remote – SSH in VS Code, without having to store my private keys in it. Since macOS allows me to store the passwords for my private SSH keys in the keychain, I can connect to the remote system without having to store any passwords or private keys in VS Code. Other SSH extensions that I tried don’t provide this feature.
I also appreciate the full-text search feature with regex support in Remote – SSH. It’s convenient to see all the search results in the editor and jump directly to the file location where the search term appears. Remote – SSH supports essentially any VS Code feature available for local folders, including debugging and git.
Nonetheless, Remote – SSH may at times cause significant CPU load on the remote server. I’ve observed that a number of vscode-server process instances can utilize up to 200% of the CPU capacity!
Should your server become inoperable due to VS Code consuming all available CPU resources, this command can terminate all vscode-server processes:
pkill -f vscode-server
As I no longer require these features (plus a few others), I prepared the following Bash script.
Script to restrict VS Code CPU usage
Here’s a breakdown of its components:
Variables
MAX_CPU_USAGE=30: Sets the maximum CPU percentage allowed for each VSCode process.
LOG_FILE=”/var/log/vscode-cpulimit.log”: Designates the file path where the log for the script will be kept.
Infinite loop (while true)
Continual monitoring and restriction of the CPU utilization by VSCode processes is allowed due to the script’s infinite loop.
Finding VSCode PIDs
The script employs the ps aux command to list all the processes that are currently running. It then further filters this list to include only the ‘vscode’ processes using the grep command. In order to exclude the grep process itself, another pipe to grep -v grep is used. The awk command is finally used to extract the plain process IDs (PIDs) of these VSCode processes which are subsequently stored in the VSCODE_PIDS variable.
Inspecting for VSCode processes
An if-else statement is then used to verify if the VSCODE_PIDS variable contains any data. It logs a message indicating no processes were found alongside the current date and time in a case where no VSCode running processes are found (i.e., the VSCODE_PIDS variable is empty).
Conversely, the script iterates over each PID when VSCode processes are found.
Applying CPU limit
Within the loop, for each PID, the script employs the cpulimit command to confine its CPU usage to the percentage delineated in the MAX_CPU_USAGE variable. This action is subsequently logged, with details such as the date, time, and PID on which the limit is enforced.
Logging
All log messages are subsequently attached to the file outlined in the LOG_FILE variable. The tee -a command inscribes the output to the log file while simultaneously presenting it on the display. If you believe that the scripts operate sufficiently, you can opt to disable logging.
Sleep
After processing all current VSCode processes, the script sleeps for 60 seconds (sleep 60) before rechecking and applying limits again.
#!/bin/bash
# Define the maximum CPU percentage you want to allow for each VSCode process
MAX_CPU_USAGE=30
# Specify the log file location
LOG_FILE="/var/log/vscode-cpulimit.log"
while true; do
# Find the PIDs of all VSCode processes (adjust the grep pattern if necessary)
VSCODE_PIDS=$(ps aux | grep 'vscode' | grep -v grep | awk '{print $2}')
# Check if any VSCode processes are running
if [ -z "$VSCODE_PIDS" ]; then
echo "[$(date)] No VSCode processes found." | tee -a $LOG_FILE
else
# Apply the CPU limit to each VSCode process
for PID in $VSCODE_PIDS
do
cpulimit -p $PID -l $MAX_CPU_USAGE &
echo "[$(date)] CPU limit of $MAX_CPU_USAGE% applied to VSCode process with PID: $PID" | tee -a $LOG_FILE
done
fi
# Sleep for a specified amount of time before checking again
sleep 60
done
This script runs indefinitely until it’s manually stopped or the system is shut down, continuously checking and limiting the CPU usage of any VSCode processes every minute.
Save the script with the name vscode-cpulimit.sh and then make sure that it can be executed:
chmod +x vscode-cpulimit.sh
Now run the script:
sudo ./vscode-cpulimit.sh
If you want to launch the script when your Linux system boots up, you can add it to cron.
crontab -e
Then add this line:
@reboot /your_path/vscode-cpulimit.sh
Conclusion
To ensure that the script is functioning properly, you can employ a monitoring tool such as top, htop, or glances. Ideally, the CPU usage of the VSCode processes should not exceed 30%. Visual Code did not appear to be slower compared to unrestricted configuration.