Ankündigung

Einklappen
Keine Ankündigung bisher.

LBS 19001280 - Unifi AP Control

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    #16
    Wenn Du in der Console ein "top" startest und dann auf "M" drueckst: welche Eintraege stehen dann ganz oben in der Liste?

    Kommentar


      #17
      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


        #18
        Kannst Du bitte nochmal die Ausgabe von "free" posten?

        Kommentar


          #19
          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


            #20
            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


              #21
              Also wenn Du mal das hier machst:
              Code:
              ps -e o pid,command,pmem,rsz,vsz k +rsz
              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).

              Wenn Du ein "cat /proc/meminfo" machst, auf welchen Wert kommst Du da bei "Inactive"?

              Kommentar


                #22
                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.png
                Zuletzt geändert von eXec; 13.06.2018, 09:13.
                ...and I thought my jokes were bad!

                Kommentar


                  #23
                  Moin,

                  Zitat von eXec Beitrag anzeigen
                  Nach jedem Boot erhöhte sich der RAM-Verbrauch um ca. 0,5% und die Load stieg um ein Vielfaches
                  Nach dem Booten erhoehte sich der Speicherbedarf? Das verstehe ich nicht - gegenueber was? Dem Speicherbedarf vor dem Booten?

                  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:
                  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
                  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...
                  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):
                  Code:
                  [root@edomi02 log]# cat /proc/loadavg
                  0.00 0.00 0.02 1/107 10289
                  (Das ist eine virtuelle CPU, also single-Core! Physikalisch haengt da ein Xeon E3@2.5 hinter...)

                  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


                    #24
                    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


                      #25
                      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


                        #26
                        Zitat von Winni Beitrag anzeigen
                        Das Speicher-Problem mit den CURL-Bausteinen hab' ich auch, bisher keine Lösung gefunden, außer Server-Neustart jede Nacht.
                        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?

                        Kommentar


                          #27
                          Zitat von Winni Beitrag anzeigen
                          bisher keine Lösung gefunden
                          Jaja, bisher

                          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):
                          PHP-Code:
                          <?php
                          $pid
                          =getmypid();

                          for (
                          $i=0;$i<300;$i++) {
                              
                          $ch=curl_init();
                              
                          curl_setopt($chCURLOPT_URL'https://www.example.org');
                              
                          curl_setopt($chCURLOPT_SSL_VERIFYHOST2);
                              
                          curl_setopt($chCURLOPT_SSL_VERIFYPEER2);
                              
                          curl_setopt($chCURLOPT_RETURNTRANSFERtrue);
                              
                          curl_exec($ch);
                              
                          curl_close($ch);
                              if (
                          $i 20 ==0) {
                                  echo 
                          "$i: PHP: ".memory_get_usage() ." - ";
                                  
                          system('cat /proc/'.$pid.'/status | grep '.'"VmSize"');
                              }
                          }
                          ?>
                          kann man deutlich sehen, wie staendig mehr Speicher belegt wird:
                          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
                          Setzt man CURLOPT_SSL_VERIFYPEER auf 0, dann sieht das ganze schon entspannter aus:
                          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 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...)

                          Die Curl-Version auf einem "untouched"-Edomi sollte die hier sein:
                          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
                          Nimmt man aber - zum Beispiel - die hier:
                          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
                          dann erzeugt obiges Skript folgende Ausgabe:
                          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
                          Moegliche Loesungsansaetze waeren also:
                          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:
                          Code:
                          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
                          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 muessen

                          Kommentar


                            #28
                            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


                              #29
                              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:
                              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
                              Bevor das aber jetzt neurotische Zuege annimmt: ich bin mir relativ sicher, dass Du eigentlich gar kein wirkliches Problem hast. Kennst Du dieses Posting?
                              https://knx-user-forum.de/forum/proj...19#post1172319

                              Kommentar


                                #30
                                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

                                Lädt...
                                X