Versions Compared

Old Version 27

changes.mady.by.user Alexis Espinosa

Saved on

compared with

New Version Current

changes.mady.by.user Alexis Espinosa

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Column
width900px


Note
titleAlways close the remote session

Always follow the exit process described above. If you don't and simply close your VS Code window, then some server-side components of VS Code will continue to run remotely.

 


Kill the leftover orphan processes in the login nodes

...

If users are performing a regular check for orphan processes, then they will need to traverse along all access the login and data-mover nodes individually and check for orphan processes on each of them. Currently there are 4 login nodes available to users going from -01 to -04.

...

width900px

...

titleOnly connect to specific login nodes to perform killing of orphan processes

...

At any given time, the set of login and data-mover nodes that are accessible may be determined by running the following commands from a terminal session on whichever login or data-mover node you have logged into

Code Block
languagetext
username@setonix-06:~> dig @150.229.2.5 setonix.pawsey.org.au
, which provides access assigning the connection to different login nodes in a round robin fashion. This allows for better load balancing of resources among all users. Furthermore, the use of the generic name provides a more reliable access as it can provide service to users on active login nodes while some specific login nodes may have been taken down by Pawsey staff for technical reasons.

Once the user has logged into the desired login node, execute the ps command together with "filtering" with the grep command acting repeatedly on the output to narrow it down to only those processes owned by the user and related to "vscode":

...

width900px
Code Block
languagebash
themeDJango
titleTerminal 2. Finding unexpected/orphan VS Code processes
$ ps -fea | head -n 1 ; ps -fea | grep ${USER} | grep -i "vscode" | grep -v "grep"
UID         PID   PPID  C STIME TTY          TIME CMD
matilda  236771      1  0 11:55 ?        00:00:00 sh /home/matilda/.vscode-server/bin/fdb98833154679dbaa7af67a5a29fe19e55c2b73/bin/code-server --start-server --host=127.0.0.1 --accept-server-license-terms --enable-remote-auto-shutdown --port=0 --telemetry-level all --connection-token-file /home/matilda/.vscode-server/.fdb98833154679dbaa7af67a5a29fe19e55c2b73.token
matilda  236784 236771  0 11:55 ?        00:00:02 /home/matilda/.vscode-server/bin/fdb98833154679dbaa7af67a5a29fe19e55c2b73/node /home/matilda/.vscode-server/bin/fdb98833154679dbaa7af67a5a29fe19e55c2b73/out/server-main.js --start-server --host=127.0.0.1 --accept-server-license-terms --enable-remote-auto-shutdown --port=0 --telemetry-level all --connection-token-file /home/matilda/.vscode-server/.fdb98833154679dbaa7af67a5a29fe19e55c2b73.token
matilda  237900 236784 99 11:55 ?        02:37:53 /home/matilda/.vscode-server/bin/fdb98833154679dbaa7af67a5a29fe19e55c2b73/node --dns-result-order=ipv4first /home/matilda/.vscode-server/bin/fdb98833154679dbaa7af67a5a29fe19e55c2b73/out/bootstrap-fork --type=extensionHost --transformURIs --useHostProxy=false
matilda  237945 236784  0 11:55 ?        00:00:00 /home/matilda/.vscode-server/bin/fdb98833154679dbaa7af67a5a29fe19e55c2b73/node /home/matilda/.vscode-server/bin/fdb98833154679dbaa7af67a5a29fe19e55c2b73/out/bootstrap-fork --type=ptyHost --logsPath /home/matilda/.vscode-server/data/logs/20231003T115510

(Note that the first part of the command above (before the semicolon ";") is to keep displaying the header of the ps command.)

As the user has already disconnected from any VS Code active session, and the "cleaning" connection is being performed outside VS Code, then users can visually confirm that those processes are indeed the orphan processes of interest. Now they can proceed to kill them by extending the command to extract a list of the process IDs and passing that list to the kill command:

...

width900px
Code Block
languagebash
themeDJango
titleTerminal 3. Killing unexpected/orphan VS Code processes
$ ps -fea | grep ${USER} | grep -i "vscode" | grep -v "grep" | awk '{print $2}' | xargs kill -9

#Confirm that after killing, no vscode process exist:
$ ps -fea | head -n 1 ; ps -fea | grep ${USER} | grep -i "vscode" | grep -v "grep"
UID         PID   PPID  C STIME TTY          TIME CMD
$

Now that users are taking some time to clean the login nodes from their orphan processes then, as recommended above, it is a good idea to go through all the active login nodes and perform a check on all of them (and kill the orphan processes that are identified).

...

  +noall +answer
setonix.pawsey.org.au.  3600    IN      A       146.118.12.26
setonix.pawsey.org.au.  3600    IN      A       146.118.12.27
setonix.pawsey.org.au.  3600    IN      A       146.118.12.22
username@setonix-06:~>
username@setonix-06:~> nslookup 146.118.12.26 150.229.2.5
26.12.118.146.in-addr.arpa      name = setonix-05.pawsey.org.au.
username@setonix-06:~>
username@setonix-06:~> nslookup 146.118.12.27 150.229.2.5
27.12.118.146.in-addr.arpa      name = setonix-06.pawsey.org.au.
username@setonix-06:~>
username@setonix-06:~> nslookup 146.118.12.22 150.229.2.5
22.12.118.146.in-addr.arpa      name = setonix-01.pawsey.org.au.
username@setonix-06:~>

Here, having logged into setonix-06, we obtain the list of IP addresses for the currently accessible login nodes, and then convert those IP addresses back into the individual nodes names.
in this instance, we can see that we should also check for leftover processe on setonix-01 and setonix-05

The following example shows the commands to obtain the list of names for the currently available data-mover nodes, having logged into setonix-dm01

Code Block
languagetext
username@setonix-dm01:~> dig @150.229.2.5 data-mover.pawsey.org.au  +noall +answer
data-mover.pawsey.org.au. 3600  IN      A       146.118.74.161
data-mover.pawsey.org.au. 3600  IN      A       146.118.74.160
data-mover.pawsey.org.au. 3600  IN      A       146.118.74.163
data-mover.pawsey.org.au. 3600  IN      A       146.118.74.162
username@setonix-dm01:~>
username@setonix-dm01:~> nslookup 146.118.74.161 150.229.2.5
161.74.118.146.in-addr.arpa      name = setonix-dm02.pawsey.org.au.
username@setonix-dm01:~>
username@setonix-dm01:~> nslookup 146.118.74.160 150.229.2.5
160.74.118.146.in-addr.arpa      name = setonix-dm01.pawsey.org.au.
username@setonix-dm01:~>
username@setonix-dm01:~> nslookup 146.118.74.163 150.229.2.5
163.74.118.146.in-addr.arpa      name = setonix-dm04.pawsey.org.au.
username@setonix-dm01:~>
username@setonix-dm01:~> nslookup 146.118.74.162 150.229.2.5
162.74.118.146.in-addr.arpa      name = setonix-dm03.pawsey.org.au.
username@setonix-dm01:~>


Column
width900px


Note
titleOnly connect to specific login nodes to perform killing of orphan processes

Only use direct connection to specific login nodes when performing cleaning of orphan processes. For the rest of your connections users should be using the generic name setonix.pawsey.org.au, which provides access assigning the connection to different login nodes in a round robin fashion. This allows for better load balancing of resources among all users. Furthermore, the use of the generic name provides a more reliable access as it can provide service to users on active login nodes while some specific login nodes may have been taken down by Pawsey staff for technical reasons.



Once the user has logged into the desired login node, execute the ps command together with "filtering" with the grep command acting repeatedly on the output to narrow it down to only those processes owned by the user and related to "vscode":

Column
width900px


Code Block
languagebash
themeDJango
titleTerminal 2. Finding unexpected/orphan VS Code processes
$ ps -fea | head -n 1 ; ps -fea | grep ${USER} | grep -i "vscode" | grep -v "grep"
UID         PID   PPID  C STIME TTY          TIME CMD
matilda  236771      1  0 11:55 ?        00:00:00 sh /home/matilda/.vscode-server/bin/fdb98833154679dbaa7af67a5a29fe19e55c2b73/bin/code-server --start-server --host=127.0.0.1 --accept-server-license-terms --enable-remote-auto-shutdown --port=0 --telemetry-level all --connection-token-file /home/matilda/.vscode-server/.fdb98833154679dbaa7af67a5a29fe19e55c2b73.token
matilda  236784 236771  0 11:55 ?        00:00:02 /home/matilda/.vscode-server/bin/fdb98833154679dbaa7af67a5a29fe19e55c2b73/node /home/matilda/.vscode-server/bin/fdb98833154679dbaa7af67a5a29fe19e55c2b73/out/server-main.js --start-server --host=127.0.0.1 --accept-server-license-terms --enable-remote-auto-shutdown --port=0 --telemetry-level all --connection-token-file /home/matilda/.vscode-server/.fdb98833154679dbaa7af67a5a29fe19e55c2b73.token
matilda  237900 236784 99 11:55 ?        02:37:53 /home/matilda/.vscode-server/bin/fdb98833154679dbaa7af67a5a29fe19e55c2b73/node --dns-result-order=ipv4first /home/matilda/.vscode-server/bin/fdb98833154679dbaa7af67a5a29fe19e55c2b73/out/bootstrap-fork --type=extensionHost --transformURIs --useHostProxy=false
matilda  237945 236784  0 11:55 ?        00:00:00 /home/matilda/.vscode-server/bin/fdb98833154679dbaa7af67a5a29fe19e55c2b73/node /home/matilda/.vscode-server/bin/fdb98833154679dbaa7af67a5a29fe19e55c2b73/out/bootstrap-fork --type=ptyHost --logsPath /home/matilda/.vscode-server/data/logs/20231003T115510


(Note that the first part of the command above (before the semicolon ";") is to keep displaying the header of the ps command.)

As the user has already disconnected from any VS Code active session, and the "cleaning" connection is being performed outside VS Code, then users can visually confirm that those processes are indeed the orphan processes of interest. Now they can proceed to kill them by extending the command to extract a list of the process IDs and passing that list to the kill command:

Column
width900px


Code Block
languagebash
themeDJango
titleTerminal 3. Killing unexpected/orphan VS Code processes
$ ps -fea | grep ${USER} | grep -i "vscode" | grep -v "grep" | awk '{print $2}' | xargs kill -9

#Confirm that after killing, no vscode process exist:
$ ps -fea | head -n 1 ; ps -fea | grep ${USER} | grep -i "vscode" | grep -v "grep"
UID         PID   PPID  C STIME TTY          TIME CMD
$


Now that users are taking some time to clean the login nodes from their orphan processes then, as recommended above, it is a good idea to go through all the active login nodes and perform a check on all of them (and kill the orphan processes that are identified).

If you find that after killing orphan processes in all the login nodes is still giving you problems to login using VS code. Then, you may need to purge the Visual Studio Code directory on Setonix using the following:

Column
width900px


Code Block
languagebash
themeDJango
titleTerminal 4. Purging the VS Code files
$ rm -rf ~/.vscode-server/


Preventing Visual Studio Code overloading the login nodes

Avoid filewatcher and file searcher to pay attention to directories with large number of files

The Visual Studio Code filewatcher and file searcher (rg) indexes all the files you have access to in your workspace. If you have a large dataset (e.g. machine learning) this can take a lot of resources on the login nodes. Please note that making some changes to your settings.json file on Setonix can prevent this issue. 

Column
width900px


Code Block
languagebash
themeDJango
titleTerminal 4. Purging the VS Code files
$ rm -rf ~/.vscode-server/

Preventing Visual Studio Code overloading the login nodes

Avoid filewatcher and file searcher to pay attention to directories with large number of files

The Visual Studio Code filewatcher and file searcher (rg) indexes all the files you have access to in your workspace. If you have a large dataset (e.g. machine learning) this can take a lot of resources on the login nodes. Please note that making some changes to your settings.json file on Setonix can prevent this issue. 

Column
width900px
# Create the settings.json file $ touch ~/.vscode-server/data/Machine/settings.json # add the following information to settings.json with your favourite text editor "files.watcherExclude": {
Code Block
languagebash
themeDJango
titleTerminal 5. Updating the settings.json file
5. Updating the settings.json file
# Create the settings.json file

$ touch ~/.vscode-server/data/Machine/settings.json

# add the following information to settings.json with your favourite text editor

"files.watcherExclude": {
  "**/.git/objects/**": true,
  "**/.git/subtree-cache/**": true,     
  "**/node_modules/*/**": true,
  "/usr/local/**": true,
  "/scratch/**": true},

"search.followSymlinks": false,

"search.exclude": {     
  "**/.git/objects/**": true,
  "**/.git/subtree-cache/**": true,     
  "**/node_modules/*/**": true,
  "/usr/local/**": true,
  "/scratch/**": true},

"search.followSymlinks": false,

"search.exclude": {     
  "**/.git/objects/**": true,
  "**/.git/subtree-cache/**": true,     
  "**/node_modules/*/**": true,
  "/usr/local/**": true,
  "/scratch/**": true},

Note that we are explicitly telling VS Code not to watch or search in directories named as indicated nor in the whole /scratch file system. And, if you know of some other directory in your files that contain a large number of files and on which you really don't need VS Code to pay attention to its contents and changes, then it is highly recommended to add its name within the settings as "**/knownDirectoryWithLotsOfFiles/**".

Disable TypeScript and JavaScript Language Services

It's also important to disable the TypeScript and JavaScript Language Services. 

  1. Hit the extensions button in VS Code (which looks like building blocks on the left toolbar)
  2. Search for ‘@builtin TypeScript’.
  3. Disable the TypeScript and Javascript Language Features extension
  4. Reload

Image Removed

Preventing Visual Studio Code to consume your quota in the $HOME file system

Home is often used by a variety of programs use store configuration files and directories along with some cached information. These directories can contain many files and use up quite a bit of storage. An example is vscode, which stores quite a bit of data within the .vscode-server  directory located in $HOME . This directory can contain upwards of 1000 files and use on the order of 100 MB. This will impact your quota on home. We recommend moving such directories to /software/projects/<project>/<username>  and generating a symbolic link in $HOME.

Column
Code Block
languagebash
themeDJango
titleTerminal X. Setting .vscode-server directory out of the HOME directory
$ mv .vscode-server $MYSOFTWARE/ # if .vscode_server already exists 
$ mkdir $MYSOFTWARE/.vscode-server # if the directory does not exist yet
$ cd $HOME
$ ln -s $MYSOFTWARE/.vscode-server # generate a symbolic link, make sure you are in $HOME


Note that we are explicitly telling VS Code not to watch or search in directories named as indicated nor in the whole /scratch file system. And, if you know of some other directory in your files that contain a large number of files and on which you really don't need VS Code to pay attention to its contents and changes, then it is highly recommended to add its name within the settings as "**/knownDirectoryWithLotsOfFiles/**".

Disable TypeScript and JavaScript Language Services

It's also important to disable the TypeScript and JavaScript Language Services. 

  1. Hit the extensions button in VS Code (which looks like building blocks on the left toolbar)
  2. Search for ‘@builtin TypeScript’.
  3. Disable the TypeScript and Javascript Language Features extension
  4. Reload

Image Added

Preventing Visual Studio Code to consume your quota in the $HOME file system

Excerpt

Home is often used by a variety of programs use store configuration files and directories along with some cached information. These directories can contain many files and use up quite a bit of storage. An example is vscode, which stores quite a bit of data within the .vscode-server  directory located in $HOME . This directory can contain upwards of 1000 files and use on the order of 100 MB. This will impact your quota on home. We recommend moving such directories to a "fakeHome" directory in: /software/projects/<project>/<username>/fakeHome. Then generate a symbolic link in $HOME that points to the corresponding directory:

Column


Code Block
languagebash
themeDJango
titleTerminal X. Setting .vscode-server directory out of the HOME directory
$ mkdir -p $MYSOFTWARE/fakeHome
$ cp -r $HOME/.vscode-server $MYSOFTWARE/fakeHome   # if .vscode_server dir initially exists in $HOME
$ rm -r $HOME/.vscode-server                        # if .vscode_server dir initially exists in $HOME
$ mkdir -p $MYSOFTWARE/fakeHome/.vscode-server      # if .vscode_server did not initially existed in $HOME
$ ln -s $MYSOFTWARE/fakeHome/.vscode-server $HOME/.vscode-server       # generate a symbolic link


Note that we are using cp + rm and not mv to transfer the .vscode-server directory to another filesystem in order to get the right ownership of files in the new filesystem and remove their original ownership that is consuming the $HOME quota, otherwise the quota of the transferred files would still be assigned to $HOME quota.

Further explanation of quotas can be found in Pawsey Filesystems and their Use.

Related pages

External links