Mam takie pytanie - myślałem, że ssh działa tak, że dopiero po zatwierdzeniu komendy jest ona wysyłana do serwera i zwracana jest odpowiedź. Jest jednak tak, że każdy znak jest przesyłany do serwera, co powoduje, że jak serwer zamula, to samo wpisywanie tekstu zamula. No i jest to dla mnie dziwne, bo mając taki darmowy serwer z aws z 1gb ramu, co prawda kilka usług na nim mam, ale samo korzystanie z tego poprzez zamulające wpisywanie jest irytujące. Są jakieś rozwiązania na to? Praktykujecie coś takiego?
0
3
- Maszyna jest przeciążona i brakuje jej zasobów
- Masz zbyt małą przepustowość łącza / Masz zbyt duże opóźnienia w transmisji danych
1
jakiego klienta używasz?
Ja bym zaczął od https://www.google.com/search?q=speedup+ssh
0
@Marlo Taroko:
zaczął bym od uptime
a potem top albo htop
bo to nie jest normalne zamulanie, albo klient ssh jakiś dziwny
Ja polecam używać putty albo ssh innych zresztą nie znam
2
To normalne, bo tak działa SSH. Możesz spróbować https://mosh.org/ - podobno ma lokalne buforowanie. Ale lag na SSH jest związany na 99% z twoim netem - w jakim regionie odpalasz, spróbuj najbliżej ciebie. Spróbuj na nowej instancji, może faktycznie masz tam coś pokopane.
0
Dzięki wszystkim za odpowiedź. To jest darmowy serwer vps od aws położony z tego co pamiętam to w Niemczech, ma bardzo słabe parametry, typu 1 rdzeń cpu, 1 gb ram. Mój internet raczej nie jest problemem, wyciągam ok. 300/300 mbps po wifi. Łączę się po ssh z wsl. Po prostu dziwi mnie to, że wpisywanie każdej literki zależy od internetu, czy obciążenia maszyny. Przecież jak wpisuję ten komentarz w polu tekstowym w przeglądarce, to mój internet, czy serwer 4programmers może nawet nie działać, a dopiero po zatwierdzeniu komentarza otrzymuję informację zwrotną. Nie bardzo wiem jak ma to działać w sytuacji, gdy robimy coś po ssh na serwerze po 2 stronie globu. Przecież po wpisaniu 1 literki czekałoby się np. 100 ms aż się ona pojawi na ekranie.
Rozumiem, że wszystko dzieje się "server side", czyli jak klikam literkę jest ona przesyłana na serwer docelowy i widzę odpowiedź zwrotną? To chyba spowoduje, że aliasy nie działają, prawda? Wydaje mi się to dziwne, no bo jak łączymy się ciągle z różnymi serwerami po ssh, to tam nie będziemy mieć tych skrótów, które używamy np. na swoim komputerze w terminalu.
Wkleję jeszcze wynik top:
top - 00:00:17 up 102 days, 4:06, 2 users, load average: 0.22, 0.22, 0.13
Tasks: 154 total, 1 running, 153 sleeping, 0 stopped, 0 zombie
%Cpu(s): 2.3 us, 1.0 sy, 0.0 ni, 96.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.3 st
MiB Mem : 957.1 total, 59.1 free, 528.0 used, 370.0 buff/cache
MiB Swap: 0.0 total, 0.0 free, 0.0 used. 218.3 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1008 root 20 0 1466380 54620 13404 S 1.0 5.6 289:25.03 dockerd
444 root 20 0 1374456 24212 6080 S 0.3 2.5 240:15.82 containerd
1118231 root 20 0 721012 3132 704 S 0.3 0.3 41:26.86 containerd-shim
1928067 root 20 0 715132 9460 2232 S 0.3 1.0 94:50.18 ctop
3466240 ubuntu 20 0 17180 7988 5456 S 0.3 0.8 0:00.04 sshd
3656261 root 20 0 716956 11536 3736 S 0.3 1.2 20:30.36 watchtower
1 root 20 0 167632 9648 4768 S 0.0 1.0 35:46.97 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.53 kthreadd
3 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_gp
4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_par_gp
5 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 slub_flushwq
6 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 netns
8 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/0:0H-events_highpri
10 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 mm_percpu_wq
11 root 20 0 0 0 0 I 0.0 0.0 0:00.00 rcu_tasks_rude_kthread
12 root 20 0 0 0 0 I 0.0 0.0 0:00.00 rcu_tasks_trace_kthread
13 root 20 0 0 0 0 S 0.0 0.0 4:53.83 ksoftirqd/0
14 root 20 0 0 0 0 I 0.0 0.0 3:47.00 rcu_sched
15 root rt 0 0 0 0 S 0.0 0.0 0:43.22 migration/0
16 root -51 0 0 0 0 S 0.0 0.0 0:00.00 idle_inject/0
18 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/0
19 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kdevtmpfs
20 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 inet_frag_wq
21 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kauditd
22 root 20 0 0 0 0 S 0.0 0.0 0:04.36 khungtaskd
24 root 20 0 0 0 0 S 0.0 0.0 0:00.00 oom_reaper
25 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 writeback
27 root 20 0 0 0 0 S 0.0 0.0 3:21.93 kcompactd0
28 root 25 5 0 0 0 S 0.0 0.0 0:00.00 ksmd
29 root 39 19 0 0 0 S 0.0 0.0 0:50.48 khugepaged
30 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kintegrityd
31 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kblockd
32 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 blkcg_punt_bio
33 root 20 0 0 0 0 S 0.0 0.0 0:00.03 xen-balloon
34 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 tpm_dev_wq
35 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 ata_sff
36 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 md
37 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 edac-poller
38 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 devfreq_wq
39 root -51 0 0 0 0 S 0.0 0.0 0:00.00 watchdogd
0
Wklej jeszcze ping i traceroute do niego.
0
Nie czuję, by teraz były jakieś lagi, ale jednak nie jest to tak samo płynne jak zwykłe wpisywanie w konsolę, bez ssh
damian@DESKTOP-7I8H54M:~$ ping ********
PING ******** (********) 56(84) bytes of data.
64 bytes from ec2-********.eu-central-1.compute.amazonaws.com (********): icmp_seq=1 ttl=52 time=55.2 ms
64 bytes from ec2-********.eu-central-1.compute.amazonaws.com (********): icmp_seq=2 ttl=52 time=23.8 ms
64 bytes from ec2-********.eu-central-1.compute.amazonaws.com (********): icmp_seq=3 ttl=52 time=23.5 ms
64 bytes from ec2-********.eu-central-1.compute.amazonaws.com (********): icmp_seq=4 ttl=52 time=41.3 ms
64 bytes from ec2-********.eu-central-1.compute.amazonaws.com (********): icmp_seq=5 ttl=52 time=64.0 ms
64 bytes from ec2-********.eu-central-1.compute.amazonaws.com (********): icmp_seq=6 ttl=52 time=64.7 ms
64 bytes from ec2-********.eu-central-1.compute.amazonaws.com (********): icmp_seq=7 ttl=52 time=23.5 ms
^C
--- ******** ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6010ms
rtt min/avg/max/mdev = 23.476/42.289/64.708/17.671 ms
damian@DESKTOP-7I8H54M:~$ traceroute ********
traceroute to ******** (********), 30 hops max, 60 byte packets
1 DESKTOP-7I8H54M.mshome.net (172.29.224.1) 0.530 ms 0.509 ms 0.501 ms
2 192.168.1.1 (192.168.1.1) 5.922 ms 5.916 ms 5.911 ms
3 100.91.32.1 (100.91.32.1) 10.471 ms 10.466 ms 10.462 ms
4 192.168.37.102 (192.168.37.102) 5.801 ms 192.168.37.6 (192.168.37.6) 10.807 ms 5.849 ms
5 e91-150.icpnet.pl (46.238.91.150) 10.796 ms 5.779 ms 5.774 ms
6 e91-141.icpnet.pl (46.238.91.141) 10.773 ms 8.356 ms 8.344 ms
7 212.162.29.165 (212.162.29.165) 55.388 ms 74.025 ms 67.080 ms
8 ae2.3217.ear5.Frankfurt1.level3.net (4.69.163.62) 68.418 ms * 67.071 ms
9 * Amazon-level3-Frankfurt1.Level3.net (4.68.62.122) 70.826 ms *
10 * * *
11 * * *
12 * * *
13 * * *
14 ec2-********.eu-central-1.compute.amazonaws.com (********) 49.329 ms 49.321 ms 49.314 ms