Wenn Du in der Console ein "top" startest und dann auf "M" drueckst: welche Eintraege stehen dann ganz oben in der Liste?
-
-
HTML-Code:login as: root root@10.0.0.240's password: [root@localhost ~]# top top - 13:02:26 up 4:52, 1 user, load average: 0.47, 0.27, 0.17 Tasks: 96 total, 2 running, 93 sleeping, 0 stopped, 1 zombie Cpu(s): 14.6%us, 4.7%sy, 0.0%ni, 80.5%id, 0.0%wa, 0.0%hi, 0.2%si, 0.0%st Mem: 3891336k total, 1925876k used, 1965460k free, 48688k buffers Swap: 1560568k total, 0k used, 1560568k free, 278236k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1543 mysql 20 0 1319m 246m 6072 S 18.3 6.5 128:18.32 mysqld 31242 root 20 0 297m 18m 9188 S 0.0 0.5 0:02.28 php 31176 root 20 0 295m 16m 9152 S 1.0 0.4 0:08.55 php 30774 root 20 0 283m 15m 7208 S 0.3 0.4 0:18.42 php 31155 root 20 0 282m 14m 7392 R 6.3 0.4 2:02.74 php 31157 root 20 0 282m 14m 7108 S 3.3 0.4 0:45.63 php 31153 root 20 0 281m 13m 6972 S 5.6 0.3 1:10.10 php 31350 root 20 0 281m 12m 6844 S 1.0 0.3 0:08.08 php 31353 root 20 0 281m 12m 6844 S 1.0 0.3 0:08.15 php 31142 root 20 0 280m 11m 6960 S 0.3 0.3 0:03.61 php 31139 root 20 0 280m 11m 6876 S 1.7 0.3 0:20.86 php 1317 root 20 0 210m 9820 5200 S 0.0 0.3 0:08.47 httpd 5458 apache 20 0 222m 9132 2840 S 0.7 0.2 0:00.31 httpd 5315 apache 20 0 222m 9128 2840 S 0.7 0.2 0:00.29 httpd
...and I thought my jokes were bad!Kommentar
-
Kannst Du bitte nochmal die Ausgabe von "free" posten?Kommentar
-
HTML-Code:[root@localhost ~]# free total used free shared buffers cached Mem: 3891336 1976164 1915172 0 52348 278916 -/+ buffers/cache: 1644900 2246436 Swap: 1560568 0 1560568 [root@localhost ~]#...and I thought my jokes were bad!Kommentar
-
Jetzt sind es 51%....
HTML-Code:top - 20:35:17 up 12:25, 1 user, load average: 0.20, 0.25, 0.22 Tasks: 95 total, 2 running, 93 sleeping, 0 stopped, 0 zombie Cpu(s): 22.1%us, 5.6%sy, 0.0%ni, 72.0%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st Mem: 3891336k total, 2355688k used, 1535648k free, 75984k buffers Swap: 1560568k total, 0k used, 1560568k free, 283504k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1543 mysql 20 0 1383m 247m 6076 S 31.5 6.5 302:39.94 mysqld 31242 root 20 0 304m 26m 9188 S 0.0 0.7 0:45.88 php 31176 root 20 0 295m 16m 9152 S 0.7 0.4 3:11.60 php 30774 root 20 0 283m 15m 7208 S 0.0 0.4 1:42.33 php
HTML-Code:[root@localhost ~]# free total used free shared buffers cached Mem: 3891336 2354952 1536384 0 75992 283512 -/+ buffers/cache: 1995448 1895888 Swap: 1560568 0 1560568 [root@localhost ~]#...and I thought my jokes were bad!Kommentar
-
Also wenn Du mal das hier machst:
und dann all die MEM-Werte zusammenzaehlst, wirst Du hoechstwahrscheinlich unter deinen 51% bleiben. Das sieht jedenfalls nicht nach einem Memory Leak aus (den die UniFi Bausteine eh nicht verursachen koennten, weil sie ja nicht dauerhaft laufen).Code:ps -e o pid,command,pmem,rsz,vsz k +rsz
Wenn Du ein "cat /proc/meminfo" machst, auf welchen Wert kommst Du da bei "Inactive"?Kommentar
-
Moin,
habe den Server per Backup zurückgesetzt, war mir zu heikel, da Prod-System. Heute Morgen alle Bausteine waren deaktiviert mit folgenden Ergebnis:
bevor.png
Danach die 4 Bausteine aktiviert und den Server mehrmals neu gebooted. Nach jedem Boot erhöhte sich der RAM-Verbrauch um ca. 0,5% und die Load stieg um ein Vielfaches:
danach.png
ps -e o pid,command,pmem,rsz,vsz k +rsz bei 17% Ram Auslastung ergibt 10,1
Cat ergab folgendes:
[root@localhost ~]# cat /proc/meminfo
MemTotal: 3891336 kB
MemFree: 1755328 kB
Buffers: 65384 kB
Cached: 1380660 kB
SwapCached: 0 kB
Active: 777656 kB
Inactive: 1000700 kB
Jetzt nach ein paar Stunden wartens ist die Load wieder auf "normal" aber die RAM-Auslastung steigt permanent:
später.pngZuletzt geändert von eXec; 13.06.2018, 09:13....and I thought my jokes were bad!Kommentar
-
Moin,
Nach dem Booten erhoehte sich der Speicherbedarf? Das verstehe ich nicht - gegenueber was? Dem Speicherbedarf vor dem Booten?Zitat von eXec Beitrag anzeigen
Das die Load beim Starten von Edomi hochgeht ist hingegen nichts ungewoehnliches, das habe ich auch - sogar ganz ohne UniFi Bausteine (im Uebrigen ist die Load ein recht theoretischer Wert, eine "sinnvoll genutzte" Quad-Core-CPU sollte zB im Idealfall stets eine Load von 4 haben).
Wie schon erwaehnt handelt es sich bei den UniFi-Bausteinen nicht um permanent laufende Prozesse, sondern um staendig neu gestartet Skripte. Wuerden diese Speicher allokieren der beim Skript-Ende nicht mehr freigegeben wird, so waere das ein relativ schwerwiegender Bug im Kernel. Ich wollte das aber nicht pauschal ausschliessen, sondern habe mal eine NigelNagelNeue und total jungfraeuliche Test-VM aufgesetzt, der ich ganz grosszuegig satte 512MB Speicher spendiert habe.
Dann hab ich ein Update fuer curl und nss gefahren und schliesslich eine Logik-Seite zusammengebastelt, die 4 Instanzen des UniFI-Control-LBS alle 10 Sekunden einmal triggert:
unifiapmem.png
Dann habe ich das Projekt aktiviert und mit per vmstat alle 30s (also nach jeweils 3 Aufrufen) den Speicher rauswerfen lassen. Das ganze 100 Mal, also 50 Minuten lang. Rausgekommen ist das hier:
Wie man sehen kann liegt der Speicherbedarf zu Beginn (ab etwa der 4. Zeile ist das Projekt aktiv) bei ca 227MB und am Ende der Messung bei ca. 209 MB, also relativ statisch - wobei gut sichtbar ist wie immer mehr "langweilige Daten" als inaktiv geflagged werden Daneben kann man noch recht schoen erkennen wie der Kernel den verfuegbaren Speicher erst komplett belegt und sich dann am Ende bei ca 32MB "Reserve" einpendelt. Wichtig auch, dass wahrend der gesamten Aufzeichnung nicht ein einziges Byte geswapped wurde...Code:procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu----- r b swpd free inact active si so bi bo in cs us sy id wa st 0 0 0 212720 68992 161304 0 0 56 32 66 244 1 1 98 0 0 0 0 0 211348 70384 161088 0 0 2 266 150 560 3 1 96 0 0 0 0 0 206256 70312 161788 0 0 0 53 143 458 4 1 95 0 0 0 0 0 202148 70356 161852 0 0 0 16 126 460 4 1 95 0 0 0 0 0 197824 70404 161844 0 0 0 11 121 444 4 1 95 0 0 0 0 0 193848 70456 161860 0 0 0 11 124 450 4 1 95 0 0 0 0 0 190128 70504 161876 0 0 0 11 121 454 4 1 95 0 0 0 0 0 186400 70548 161900 0 0 0 12 122 459 4 1 95 0 0 0 0 0 182688 70600 161916 0 0 0 12 124 456 4 1 95 0 0 0 0 0 179084 70644 161936 0 0 0 12 129 458 4 1 95 0 0 0 0 0 175512 70756 161884 0 0 3 12 123 458 4 1 95 0 0 0 0 0 171412 70732 162016 0 0 0 11 130 459 4 1 95 0 0 0 0 0 167700 70768 162048 0 0 0 11 128 447 4 1 95 0 0 0 0 0 163732 70816 162064 0 0 0 11 119 443 4 1 95 0 0 0 0 0 160012 70864 162080 0 0 0 12 120 448 4 1 95 0 0 0 0 0 156532 70912 162096 0 0 0 10 118 441 4 1 95 0 0 0 0 0 153052 70960 162116 0 0 0 12 120 452 4 1 95 0 0 0 0 0 149340 71008 162136 0 0 0 11 120 441 4 1 95 0 0 0 0 0 146356 71056 162156 0 0 0 12 121 441 4 1 95 0 0 0 0 0 143140 71104 162172 0 0 0 10 122 444 4 1 95 0 0 1 0 0 139792 71152 162188 0 0 0 11 121 433 4 1 95 0 0 0 0 0 136444 71200 162208 0 0 0 12 121 438 4 1 95 0 0 0 0 0 133344 71248 162224 0 0 0 11 118 439 4 1 95 0 0 0 0 0 130120 71296 162244 0 0 0 11 118 439 4 1 95 0 0 0 0 0 126772 71348 162256 0 0 0 11 118 436 4 1 95 0 0 0 0 0 123424 71392 162280 0 0 0 12 124 438 4 1 95 0 0 0 0 0 119952 71440 162296 0 0 0 11 118 434 4 1 95 0 0 0 0 0 116356 71488 162316 0 0 0 10 118 439 4 1 95 0 0 0 0 0 113124 71536 162336 0 0 0 12 120 432 4 1 95 0 0 0 0 0 109536 71584 162352 0 0 0 11 118 431 4 1 95 0 0 1 0 0 106312 71632 162368 0 0 0 12 119 437 4 1 95 0 0 0 0 0 102840 71680 162388 0 0 0 10 120 444 4 1 95 0 0 1 0 0 99616 71728 162404 0 0 0 12 120 450 4 1 95 0 0 0 0 0 96268 71780 162420 0 0 0 11 118 438 4 1 95 0 0 0 0 0 93292 71824 162440 0 0 0 11 122 426 4 1 95 0 0 0 0 0 90068 71872 162460 0 0 0 12 119 429 4 1 95 0 0 0 0 0 87216 71920 162472 0 0 0 10 120 440 4 1 95 0 0 0 0 0 84364 71968 162496 0 0 0 12 121 437 4 1 95 0 0 0 0 0 81388 72016 162512 0 0 0 11 119 439 4 1 95 0 0 0 0 0 78288 72060 162532 0 0 0 12 119 451 4 1 95 0 0 0 0 0 75436 72108 162544 0 0 0 12 120 441 4 1 95 0 0 0 0 0 72336 72160 162568 0 0 0 11 119 445 4 1 95 0 0 0 0 0 69236 72208 162584 0 0 0 12 120 455 4 1 95 0 0 0 0 0 66384 72256 162600 0 0 0 11 118 449 4 1 95 0 0 0 0 0 63284 72300 162616 0 0 0 12 119 444 4 1 95 0 0 0 0 0 60432 72348 162636 0 0 0 12 123 449 4 1 95 0 0 0 0 0 57828 72396 162656 0 0 0 12 119 446 4 1 95 0 0 0 0 0 55100 72444 162672 0 0 0 12 120 444 4 1 95 0 0 0 0 0 52248 72492 162692 0 0 0 10 120 446 4 1 95 0 0 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu----- r b swpd free inact active si so bi bo in cs us sy id wa st 2 0 0 49520 72540 162708 0 0 0 12 120 446 4 1 95 0 0 0 0 0 46916 72584 162724 0 0 0 12 120 445 4 1 95 0 0 0 0 0 44244 72636 162752 0 0 0 13 123 453 4 1 95 0 0 0 0 0 41884 72680 162768 0 0 0 12 126 445 4 1 95 0 0 0 0 0 39712 72728 162788 0 0 0 12 124 452 4 2 95 0 0 0 0 0 37240 72776 162800 0 0 0 12 119 450 4 1 95 0 0 0 0 0 34468 72824 162824 0 0 0 11 120 449 4 1 95 0 0 0 0 0 31924 72872 162840 0 0 0 12 120 440 4 1 95 0 0 0 0 0 32088 74668 160608 0 0 0 12 122 438 4 1 94 1 0 0 0 0 32676 76648 158184 0 0 0 13 121 438 4 1 95 0 0 0 0 0 33316 78496 155888 0 0 0 13 120 442 4 1 95 1 0 0 0 0 32676 79424 154788 0 0 0 12 118 450 4 1 95 0 0 0 0 0 33824 80260 152600 0 0 1 12 122 450 4 1 95 0 0 0 0 0 34876 81892 150692 0 0 6 11 121 449 4 1 95 0 0 0 0 0 32644 81940 150712 0 0 0 12 120 432 4 1 95 0 0 0 0 0 31940 82892 149572 0 0 0 12 120 432 4 1 95 0 0 2 0 0 26808 85140 153396 0 0 0 13 124 442 4 2 94 0 0 3 0 0 13196 86168 164500 0 0 6 13 113 421 3 1 95 0 0 0 0 0 13672 82924 165888 0 0 1 10 118 430 4 1 95 0 0 0 0 0 11504 82972 165908 0 0 0 12 119 430 4 1 95 0 0 0 0 0 9072 83020 165928 0 0 0 11 118 435 4 1 95 0 0 4 0 0 14604 83068 159168 0 0 0 13 110 426 3 1 96 0 0 0 0 0 33068 84068 140560 0 0 2 13 116 429 3 1 95 0 0 0 0 0 32656 85012 139428 0 0 0 11 120 435 4 1 95 0 0 0 0 0 31972 86084 138168 0 0 0 12 119 439 4 1 95 0 0 0 0 0 33200 88064 135892 0 0 4 12 119 440 4 1 95 0 0 0 0 0 32744 89012 134716 0 0 0 12 119 444 4 1 95 0 0 0 0 0 31872 89972 133380 0 0 0 11 120 446 4 1 95 0 0 0 0 0 32804 88972 131860 0 0 0 11 119 452 4 1 95 0 0 0 0 0 32424 90056 130576 0 0 0 12 119 445 4 1 95 0 0 0 0 0 32180 91032 129408 0 0 0 12 119 452 3 1 95 0 0 0 0 0 33728 93000 126984 0 0 0 12 120 449 4 1 95 0 0 0 0 0 31876 93044 127004 0 0 0 12 123 449 4 1 95 0 0 0 0 0 33412 94928 124676 0 0 0 12 121 452 4 1 95 1 0 0 0 0 34500 95204 122880 0 0 2 10 121 442 4 1 95 0 0 0 0 0 32152 95204 122636 0 0 0 12 121 448 4 1 95 0 0 0 0 0 34236 97176 120212 0 0 0 12 123 449 4 1 94 0 0 0 0 0 33652 98196 118996 0 0 0 12 121 445 4 1 95 0 0 0 0 0 33556 99304 117740 0 0 2 11 121 443 4 1 95 0 0 2 0 0 33180 100476 116384 0 0 0 12 120 446 4 1 95 0 0 0 0 0 33032 101588 115076 0 0 0 12 122 452 4 1 95 0 0 0 0 0 32408 102712 113756 0 0 0 11 121 451 4 1 95 0 0 0 0 0 32648 103132 111448 0 0 0 11 119 450 3 1 95 0 0 0 0 0 32148 104076 110308 0 0 0 12 118 433 4 1 95 0 0 0 0 0 31832 105036 109180 0 0 0 12 121 438 4 1 95 0 0 0 0 0 32716 107096 107148 0 0 7 12 120 435 3 1 95 0 0 0 0 0 33008 108456 105756 0 0 5 11 120 430 4 1 95 0 0 0 0 0 32800 109464 104612 0 0 2 11 120 433 4 1 95 0 0 0 0 0 32752 110516 103444 0 0 1 11 120 431 4 1 95 0 0 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu----- r b swpd free inact active si so bi bo in cs us sy id wa st 0 0 0 32608 111416 102384 0 0 0 12 119 435 4 1 95 0 0 0 0 0 32472 112492 101136 0 0 0 11 118 434 3 1 95 0 0
Desweiteren kann man sehen, dass die CPU-Auslastung bei ziemlich konstanten 5% liegt und wo ich grad dabei war, hier mal die aktuelle Load (am Ende der Messung):
(Das ist eine virtuelle CPU, also single-Core! Physikalisch haengt da ein Xeon E3@2.5 hinter...)Code:[root@edomi02 log]# cat /proc/loadavg 0.00 0.00 0.02 1/107 10289
Wo auch immer deine Speicher- (und evtl. auch CPU-) Geschichte ihre Ursache findet (es sind jedenfalls ganz sicher nicht die UniFi-Bausteine) - da kann ich Dir leider nicht helfen, musst du wohl woanders weiter suchen.
Und weil das ja quasi von alleine funktioniert mache ich jetzt nochmal ein CentOS-Update auf der VM und lasse die selbe Messung nochmal durchlaufen, vielleicht auch nochmal mit deaktivierten Bausteinen. Die Ergebnisse schiebe ich dann nach...Kommentar
-
Hmmm....ich habe die Bausteine deaktiviert und das Problem scheint weg zu ... Dann weiß ich auch nicht
Sobald ich diese wiede aktiviere springt die Ram-Nutzung wie beschrieben.
Ist irgendwie unbefriedigend.
Aber danke für deine Mühen.
Ich setzte den Edomi mal neu auf in einer VM und lade mein Backup da rein und versuche dort den Effekt mal zu erziehlen.
...and I thought my jokes were bad!Kommentar
-
Nur mal am Rande bemerkt: Das Speicher-Problem mit den CURL-Bausteinen hab' ich auch, bisher keine Lösung gefunden, außer Server-Neustart jede Nacht.
Ich hoffe es tut sich mal was in Bezug auf PHP Version, damit ließe sich wohl unter anderem (Multicast) dieses Problem lösen.Kommentar
-
Das Problem sollte aber nur bei Bausteinen auftreten die permanent laufen, also ein klassisches Memory-Leak... wird der Daemon-Prozess beendet (also nur der LBS, nicht der ganze Edomi-Prozess) sollte der Speicher auf jeden Fall wieder freigegeben werden?Zitat von Winni Beitrag anzeigen
Kommentar
-
Jaja, bisherZitat von Winni Beitrag anzeigen
Also das Problem (das dauerhaft laufende Bausteine immer mehr Speicher konsumieren) ist ein Memory Leak in libcurl. Das wissen auch alle Beteiligten (also zumindest die Maintainer von curl als auch die von Redhat/CentOS), aber irgendwie will da keiner bei - wieso auch immer. Das Problem tritt auf wenn die Option SSL_VERIFYPEER gesetzt ist, dann wird beim Zerstoeren des Curl-Handles nicht mehr der gesamte Speicher freigegeben. Wenn man zB das folgende Skript ausfuehrt (vielleicht am besten "www.example.org" durch irgendeine lokale URL ersetzen):
kann man deutlich sehen, wie staendig mehr Speicher belegt wird:PHP-Code:<?php
$pid=getmypid();
for ($i=0;$i<300;$i++) {
$ch=curl_init();
curl_setopt($ch, CURLOPT_URL, 'https://www.example.org');
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 2);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_exec($ch);
curl_close($ch);
if ($i % 20 ==0) {
echo "$i: PHP: ".memory_get_usage() ." - ";
system('cat /proc/'.$pid.'/status | grep '.'"VmSize"');
}
}
?>
Setzt man CURLOPT_SSL_VERIFYPEER auf 0, dann sieht das ganze schon entspannter aus:Code:[root@edomi02 ~]# php curl.php 0: PHP: 626216 - VmSize: 268284 kB 20: PHP: 626248 - VmSize: 270324 kB 40: PHP: 626248 - VmSize: 270324 kB 60: PHP: 626248 - VmSize: 270324 kB 80: PHP: 626248 - VmSize: 270456 kB 100: PHP: 626248 - VmSize: 270852 kB 120: PHP: 626248 - VmSize: 271956 kB 140: PHP: 626248 - VmSize: 271956 kB 160: PHP: 626248 - VmSize: 271956 kB 180: PHP: 626248 - VmSize: 272224 kB 200: PHP: 626248 - VmSize: 272620 kB 220: PHP: 626248 - VmSize: 272884 kB 240: PHP: 626248 - VmSize: 273280 kB 260: PHP: 626248 - VmSize: 273544 kB 280: PHP: 626248 - VmSize: 273940 kB
(Die betreffende Option sollte eigentlich in allen meinen LBS auf "0" stehen, da sollte dieses Problem also generell nicht auftauchen, egal ob das nun EXEC-Skripte oder Daemons sind...)Code:[root@edomi02 ~]# php curl.php 0: PHP: 626216 - VmSize: 267372 kB 20: PHP: 626248 - VmSize: 267512 kB 40: PHP: 626248 - VmSize: 267512 kB 60: PHP: 626248 - VmSize: 267512 kB 80: PHP: 626248 - VmSize: 267512 kB 100: PHP: 626248 - VmSize: 267512 kB 120: PHP: 626248 - VmSize: 267512 kB 140: PHP: 626248 - VmSize: 267512 kB 160: PHP: 626248 - VmSize: 267512 kB 180: PHP: 626248 - VmSize: 267512 kB 200: PHP: 626248 - VmSize: 267512 kB 220: PHP: 626248 - VmSize: 267512 kB 240: PHP: 626248 - VmSize: 267512 kB 260: PHP: 626248 - VmSize: 267512 kB 280: PHP: 626248 - VmSize: 267512 kB
Die Curl-Version auf einem "untouched"-Edomi sollte die hier sein:
Nimmt man aber - zum Beispiel - die hier:Code:[root@edomi-ha-master ~]# curl --version curl 7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.0.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2 Protocols: tftp ftp telnet dict ldap ldaps http file https ftps scp sftp Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz
dann erzeugt obiges Skript folgende Ausgabe:Code:[root@edomi02 ~]# curl --version curl 7.60.0 (x86_64-redhat-linux-gnu) libcurl/7.60.0 OpenSSL/1.0.1e zlib/1.2.3 c-ares/1.14.0 libssh2/1.8.0 nghttp2/1.6.0 Release-Date: 2018-05-16 Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp Features: AsynchDNS IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz HTTP2 UnixSockets HTTPS-proxy Metalink
Moegliche Loesungsansaetze waeren also:Code:[root@edomi02 ~]# php curl.php 0: PHP: 626216 - VmSize: 256904 kB 20: PHP: 626248 - VmSize: 256904 kB 40: PHP: 626248 - VmSize: 256904 kB 60: PHP: 626248 - VmSize: 256904 kB 80: PHP: 626248 - VmSize: 256904 kB 100: PHP: 626248 - VmSize: 256904 kB 120: PHP: 626248 - VmSize: 256904 kB 140: PHP: 626248 - VmSize: 256904 kB 160: PHP: 626248 - VmSize: 256904 kB 180: PHP: 626248 - VmSize: 256904 kB 200: PHP: 626248 - VmSize: 256904 kB 220: PHP: 626248 - VmSize: 256904 kB 240: PHP: 626248 - VmSize: 256904 kB 260: PHP: 626248 - VmSize: 256904 kB 280: PHP: 626248 - VmSize: 256904 kB
1) Die Option SSL_VERIFYPEER auf 0 zu setzen: was - wie gesagt - bei allen Bausteinen von mir mittlerweile der Fall sein sollte (auch jonofe hat das wohl mittlerweile in einigen LBS so abgeaendert)
2) Eine fehlerfreie Curl-Version zu verwenden: das ist schon schwieriger, denn wie oben beschrieben interessiert sich irgendwie keiner wirklich dafuer und selber Kompilieren will man das ja auch nicht unbedingt...
Folgende Befehlssequenz installiert eine aktuellere Curl-Version, bei der dieses spezifische Problem nicht mehr auftreten sollte:
Mag aber sein, dass irgendwelche LBS damit nicht mehr 100%ig klarkommen - es koennte zu Warnungen im Edomi-Log kommen. Aber wer will kann das ja mal ausprobieren - alles ist besser als jede Nacht die Maschine durchstarten zu muessenCode:yum -y install epel-release rpm -Uvh http://www.city-fan.org/ftp/contrib/yum-repo/rhel6/x86_64/city-fan.org-release-2-1.rhel6.noarch.rpm yum -y --enablerepo=city-fan.org update libcurl
Kommentar
-
Mein Problem zieht mittlerweile größere Kreise..ein Neustart behebt den Memory Leak nicht. Erst ein Backup einspielen setzt den RAM zurück... arrghh
kann ich die Curl Version wieder downgraden wenn nicht erfolgreich?Zuletzt geändert von eXec; 13.06.2018, 21:53....and I thought my jokes were bad!Kommentar
-
Dir ist aber schon klar, dass das technisch so nicht moeglich ist, oder? Wenn ein LBS deaktiviert ist und man startet das System neu, dann wird der LBS auch nicht gestartet und der dazugehoerige Code nicht ausgefuehrt und dann gibts auch kein Memory Leak...
Downgrades gehen im allgemeinen "immer", im speziellen "meistens"... Garantie gibt dir keiner, aber bei mir geht das:
Bevor das aber jetzt neurotische Zuege annimmt: ich bin mir relativ sicher, dass Du eigentlich gar kein wirkliches Problem hast. Kennst Du dieses Posting?Code:[root@edomi02 ~]# curl --version curl 7.60.0 (x86_64-redhat-linux-gnu) libcurl/7.60.0 OpenSSL/1.0.1e zlib/1.2.3 c-ares/1.14.0 libssh2/1.8.0 nghttp2/1.6.0 Release-Date: 2018-05-16 Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp Features: AsynchDNS IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz HTTP2 UnixSockets HTTPS-proxy Metalink [root@edomi02 ~]# yum -y --enablerepo=city-fan.org downgrade curl libcurl Geladene Plugins: fastestmirror Einrichten des Downgrade-Prozesses ... ... ... Entfernt: curl.x86_64 0:7.60.0-1.0.cf.rhel6 libcurl.x86_64 0:7.60.0-1.0.cf.rhel6 Installiert: curl.x86_64 0:7.19.7-53.el6_9 libcurl.x86_64 0:7.19.7-53.el6_9 Komplett! [root@edomi02 ~]# curl --version curl 7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.27.1 zlib/1.2.3 libidn/1.18 libssh2/1.4.2 Protocols: tftp ftp telnet dict ldap ldaps http file https ftps scp sftp Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz
https://knx-user-forum.de/forum/proj...19#post1172319Kommentar
-
Hmmm, gebe dir ja recht das man gegebene Ressourcen nutzen soll, aber wenn bei 92% (von 9% bei Start innerhalb einer Nacht) die Warnmeldung in Edomi kommt, ist irgendetwas nicht ok, oder?
Ich versuche das Curl Upgrade einmal...
Nach Update keine Fehler. Backup mit allen 4 aktiven Bausteinen eingespielt mit folgen Ergebnis:
14-06-_2018_08-39-49.png
Werde es mal beobachten wie sich der RAM Verlauf ändert. Bisher alles positiv!Zuletzt geändert von eXec; 14.06.2018, 07:41....and I thought my jokes were bad!Kommentar
Kommentar