Please forward this long mail to students. I hope that it will explain few things.
Ok, at first I would recommend students to run this command at their home linux computers as it will help them to choose the server with the least load.
for i in 1 2 3 4 5 6 7 8 ; do ssh -l jf tieskybs0$i.it.jyu.fi "hostname; w " ; done | grep load
Replace my username "jf" with your own username and install RSA keys to server at first. Easiest way to do this is command "ssh-copy-id username@tieskybs01.it.jyu.fi". Use your own username here too.
Ok, let's assume now that each have ssh keys in place and we can run the command above.
[jf@kukkakeppi ~]$ for i in 1 2 3 4 5 6 7 8 ; do ssh -l jf tieskybs0$i.it.jyu.fi "hostname; w " ; done | grep load 09:33:32 up 3:30, 2 users, load average: 1.37, 0.40, 0.16 09:33:33 up 3:30, 2 users, load average: 2.43, 2.62, 2.39 09:33:33 up 3:30, 1 user, load average: 0.00, 0.03, 0.19 09:33:34 up 3:30, 8 users, load average: 3.81, 4.93, 5.19 09:33:35 up 3:30, 6 users, load average: 3.88, 3.36, 2.42 09:33:36 up 3:31, 3 users, load average: 1.81, 1.35, 1.37 09:33:37 up 3:31, 4 users, load average: 1.52, 1.99, 1.31 09:33:38 up 3:30, 0 users, load average: 0.00, 0.01, 0.05 [jf@kukkakeppi ~]$
Now we can analyze the output and get some useful information. There are 2 servers, i.e. tieskybs03 and tieskybs08, which don't have any load (load average == 0.00)
Although the list shows that tieskybs03 has one user logged in while load is 0.00 there is no user. This is a ghost user hanging on the server because the corresponding actual user has not correctly logged out from the server. He or she has just killed the VNC client which have left the VNC server process running on tieskybs03. Many students behave like this so the number of ghost servers will cumulate and they are consuming both CPU time and memory. This is one reason why servers will become slower.
Also these ghost processes may prevent future logins if there are not enough free memory left for new VNC sessions. If the memory allocation fails then user is thrown out.
Finally, one reason for disconnections is that the servers are rebooting every morning at 06.00am because of those hanging VNC processes. Reboot simple cleans the servers for new day.
So the correct way to end VNC session is to logout from server at first, then close VNC client and finally close SSH tunnel. If students can do this correctly then automatic reboots can be removed.
The reason for disconnections can also be due to the actions of network operators e.g. university's digiservices, Funet, mobile and fixed network operators. They have same reason for disconnecting i.e. hanging connections (=open connection without any data traffic) consumes resources so after some timeout period connections will be dropped down.
For eaxmple, if we think about mobile data connection from home to course servers there are actually lot of different network connections between the end points. If we break this into pieces then the first connection is from student's laptop to mobile home router over wifi, then second is radio connection from mobile router to nearest 2/3/4/5G base station, the third connection from base station to network operator's private IP network, the fourth from operator's private network to network traffic exchange hubs, the fifth from the hub to Funet, the sixth from Funet to JYUNET and finally from JYUNET to faculty's server network. The connection from home to servers is made up from all these and one can never assume that they all would work flawlessly all the time. We are now talking about 7 independent systems under 7 independent administrative control which all together make the connection from home to course servers.
So, it's not good idea to leave connections open over night, especially if one has open file in some editor. Please don't even start to work like this.
Hopefully the abobe explains also why network connections can be slower or faster on daily basis. I live outside of urban area where network speeds change a lot, from 300 kbits/s to 40 Mbits/s. I would say that the network connections are like the weather: it can be almost anything in Finland so get used to it.
One reason for slow virtual machines, especially if they start to become slower and slower, can be caused also how one has allocated the disk space for his or her virtual machine. One can allocate the whole disk space at once which leads into situation where the disk space is one big continuous file or one can allocate disk space on as needed-basis which allocates more disk space as it is needed. The latter leads into situation where the disk space is fragmented over several small files which makes disk I/O slow. Also the allocation process takes time: if virtual machine needs more disk space it requests it from the server running virtual machines which makes the actual disk block reservations and returns the pointers to these blocks to virtual machine which then makes file system on these blocks before writing the actual data onto them. The other virtual machine which has allocated all space at once simply writes to data onto disk and moves into next task.
It seems to me that someone has forgotten things learned at courses on operating systems, data networks, programming and data structures. Please learn to combine things together and analyze the situation instead of just reading exercise task descriptions. It helps to survive in the deep end where one goes always while facing new things and problems.
Best regards, Juhani Forsman -- Laboratory Chief University of Jyvaskyla tel: +358-40-565 8907 Faculty of Information Technology email: jf@vrl.jyu.fi P.O.B 35 40014 University of Jyvaskyla Finland