Ich betreibe einen kleinen Server (1 GB RAM) und auch eine kleine Website (offizielle Discourse-Installation, die seit fast 8 Jahren läuft). Es gibt mehr Festplatten-Swapping als mir lieb ist, also habe ich angefangen, den Speicherverbrauch zu untersuchen.
Mir ist aufgefallen, dass ich die Anzahl der Unicorns vor einiger Zeit auf nur 2 begrenzt habe, um den Speicherverbrauch zu begrenzen (und das Swapping zu reduzieren). Discourse-Version 3.1.0 wird ausgeführt.
Was übersehe ich hier? Warum laufen 20 Unicorns, während die app.yml 2 angibt?
Gibt es außerdem andere Möglichkeiten, den Speicherverbrauch zu reduzieren (z. B. wenn ich db_shared_buffers auf 128 MB reduziere, gibt es Nebenwirkungen?) Kann ich den Speicherverbrauch von Sidekiq reduzieren?
Ich vermute, htop zeigt Threads statt Prozesse an – jedenfalls sehe ich bei htop dasselbe wie du, aber laut
ps uaxf|egrep unicorn.?worker
nur zwei Unicorns.
Auch mein free sieht aus wie deins:
# free -h
total used free shared buff/cache available
Mem: 985M 782M 61M 60M 141M 32M
Swap: 2.0G 992M 1.0G
Übrigens ist es an sich kein Problem, etwas Swap-Nutzung zu sehen. Es ist das eigentliche Swapping (Paging), das wichtig wäre. Versuche vmstat 5 5 und schau dir die Spalten si und so an.
# vmstat 5 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 1041832 63176 5716 127408 367 325 601 393 8 10 2 1 95 2 0
0 0 1041576 60976 5724 127408 399 0 399 21 212 653 1 1 96 2 0
0 0 1043544 77036 2296 120688 807 803 807 837 404 1144 1 2 94 3 0
0 0 1043288 65040 3704 129476 254 0 2292 5 255 780 1 1 96 2 0
0 0 1048736 81936 2916 119016 762 1499 919 1565 470 1171 3 2 90 5 0
Ich würde es vorziehen, nichts über 1000 zu sehen, aber ich bin nicht allzu besorgt. Ein zweiter Durchlauf zeigte ein viel ruhigeres Bild:
# vmstat 5 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 1048452 82712 2532 120848 367 325 601 393 8 10 2 1 95 2 0
0 0 1047684 74552 2548 124816 285 0 1049 10 230 655 2 1 95 2 0
0 0 1046660 66556 3692 129008 196 0 1261 16 219 672 1 1 96 2 0
1 0 1046404 65812 3700 129284 54 0 97 13 137 364 1 0 98 0 0
0 0 1046148 65280 3700 129288 50 0 50 3 132 344 1 0 98 0 0
Edit: Die H-Taste in htop wechselt zwischen Threads und Prozessen:
CPU[ 0.0%] Tasks: 66; 1 running
Mem[||||||||||||||||||||||||||||||||||||||||||||||||||824M/985M] Load average: 0.19 0.12 0.05
Swp[|||||||||||||||||||||||||||||| 1015M/2.00G] Uptime: 52 days, 00:50:42
PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
13246 1000 20 0 966M 362M 6448 S 0.0 36.8 51:01.52 unicorn worker[0] -E production -c config/unicorn.conf.rb
13237 1000 25 5 1004M 194M 3780 S 0.0 19.8 22:38.19 sidekiq 6.5.9 discourse [0 of 5 busy]
13258 1000 20 0 919M 70176 3632 S 0.0 7.0 5:02.87 unicorn worker[1] -E production -c config/unicorn.conf.rb
12412 systemd-r 20 0 212M 60928 56916 S 0.0 6.0 0:00.23 postgres: 13/main: discourse discourse [local] idle
12818 systemd-r 20 0 212M 39228 34868 S 0.0 3.9 0:00.07 postgres: 13/main: discourse discourse [local] idle
12719 systemd-r 20 0 211M 28400 25336 S 0.0 2.8 0:00.03 postgres: 13/main: discourse discourse [local] idle
13117 1000 20 0 541M 13768 2048 S 0.0 1.4 1:08.11 unicorn master -E production -c config/unicorn.conf.rb
Edit: Ich habe db_shared_buffers: "128MB" schon sehr früh gesetzt und hatte damit keine Probleme.
Danke, sehr hilfreich. Was ist der Nachteil, wenn man zu einem einzigen Unicorn-Worker wechselt? Würde das die Antwortzeit verbessern oder verschlechtern (ist ein Unicorn-Worker auf eine eingehende Verbindung beschränkt, d. h. würden 2 Worker eine einzelne eingehende Verbindung schneller verarbeiten?), vorausgesetzt, ich habe nur wenige Verbindungen pro Minute?
Wenn ich die Website durchsuche, sieht vmstat 5 5 so aus. Haben Sie Vorschläge, wie ich das Swapping reduzieren kann (ich habe die Swappiness auf 10 eingestellt)?
Es sieht sicherlich so aus, als ob Ihre Website schneller wäre, wenn Sie mehr RAM hätten. Aber wenn die Antwortzeit kein Problem darstellt, gibt es kein Problem. Betrachten Sie einfach Ihre persönliche Kosten-Nutzen-Gleichung.
Vielleicht interessiert Sie die Lektüre von MKJs Meinung zur Discourse-Deployment-Konfiguration. Es gibt ein paar Kernel-Tweaks auf Systemebene, die eine gute Idee sind. Ich weiß nicht, ob sie einen Unterschied machen werden oder nicht.
Ich weiß es nicht, aber ich denke, jedes Unicorn kann eine Anfrage bearbeiten. Wenn Sie also nur ein Unicorn haben und genügend Traffic für eine zweite Anfrage, bevor die erste abgeschlossen ist, muss diese zweite Anfrage warten. Sie können aus meiner htop-Ausgabe sehen, dass ein Unicorn 10x mehr CPU-Zeit als das andere verbraucht hat. Ich würde das so interpretieren, dass mein Forum zu 90 % der Zeit nur ein Unicorn benötigt und zu 10 % der Zeit das zweite Unicorn hilfreich ist. Ich sehe keine Notwendigkeit, ein drittes hinzuzufügen, und es wäre für meine Forenmitglieder vielleicht kein großes Problem, wenn ich auf eines reduzieren würde. Aber ich sehe keinen Grund dafür: Es mag Speicher verbrauchen, aber wenn es im Leerlauf ist, wird es ausgetauscht. Kein großes Problem: Lassen Sie das virtuelle Speichersystem damit umgehen.
Bearbeiten: Ich habe die Swappiness nie angepasst. Sie scheint bei 60 zu liegen. Aggressiveres Swapping könnte nützlich sein, wenn es mehr RAM für I/O-Puffer freigibt. Ich weiß es nicht.
Gibt es eine Möglichkeit, nur neu zu starten, ohne neu zu erstellen über ./launcher rebuild app, wenn ich db_shared_buffers und UNICORN_WORKERS ändere?
