Moin,
srv03 ist in regelmässigen Abständen Out of Memory, wir müssen mal
schauen, wodrann das liegt.
vg
Gekillt wurde jeweils php:
Killed process 12442 (php) total-vm:3990960kB, anon-rss:1622972kB, file
-rss:0kB
php läuft eigentlich nur als cronjob für den Mailabruf von OSticket,
der PHP-Webfoo wird von php-fpm erledigt.
Zitat von Bjoern Franke <bjo@nord-west.org>:
Gekillt wurde jeweils php:
Killed process 12442 (php) total-vm:3990960kB, anon-rss:1622972kB, file
-rss:0kBphp läuft eigentlich nur als cronjob für den Mailabruf von OSticket,
der PHP-Webfoo wird von php-fpm erledigt.
# grep -i kill /var/log/messages
Jul 7 17:31:54 srv03 kernel: [4559599.186271] [<ffffffff8114034d>] ? oom_kill_process+0x21d/0x370
Jul 7 17:39:25 srv03 kernel: [4560050.752464] [<ffffffff8114034d>] ? oom_kill_process+0x21d/0x370
Jul 7 18:01:27 srv03 kernel: [4561375.609444] sshd invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
Jul 7 18:01:28 srv03 kernel: [4561375.609974] [<ffffffff8114034d>] ? oom_kill_process+0x21d/0x370
Jul 8 07:32:07 srv03 kernel: [4610052.307778] /usr/sbin/munin invoked oom-killer: gfp_mask=0x200da, order=0, oom_score_adj=0
Jul 8 16:03:12 srv03 kernel: [4640743.329933] uwsgi invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
# grep -i kill /var/log/syslog
Jul 8 07:22:53 srv03 kernel: [4609495.401009] Out of memory: Kill process 12442 (php) score 624 or sacrifice child
Jul 8 07:22:53 srv03 kernel: [4609495.401053] Killed process 12442 (php) total-vm:3990960kB, anon-rss:1622972kB, file-rss:0kB
Jul 8 07:32:07 srv03 kernel: [4610052.307778] /usr/sbin/munin invoked oom-killer: gfp_mask=0x200da, order=0, oom_score_adj=0
Jul 8 16:03:12 srv03 kernel: [4640743.329933] uwsgi invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0
srv03 hat 2GB ram, das scheint zu wenig?
https://fr32k.de/pad/p/ffnw_server_hw
Jap, deswegen soll der ja auch nur noch als Supernode laufen und
web/git/mysql von srv03 auf srv01 bei Netcup mit 6GB RAM umziehen.
vg
Zitat von Bjoern Franke <bjo@nord-west.org>:
srv03 hat 2GB ram, das scheint zu wenig?
https://fr32k.de/pad/p/ffnw_server_hwJap, deswegen soll der ja auch nur noch als Supernode laufen und
web/git/mysql von srv03 auf srv01 bei Netcup mit 6GB RAM umziehen.
wenn wir alles noch nicht umziehen können,
dann lass uns einen teil umziehen,
oder z.b GITLAB im moment auschalten, da GITLAB ~1GB RAM brauch.
oder z.b GITLAB im moment auschalten, da GITLAB ~1GB RAM brauch.
Da kommt von mir gleich mal ein Hee ich bin gerade am entwickeln ihr
könnte doch nicht einfach gitlab abschalten 
LG
Tarek
Gitlab sollte weiter laufen!
Zitat von Stefan <stefan@osnabrueck.freifunk.net>:
Gitlab sollte weiter laufen!
natürlich, wenns geht!
srv03 hat 2GB ram, das scheint zu wenig?
https://fr32k.de/pad/p/ffnw_server_hw
pic und ich haben nun herausgefunden, dass der cron-Aufruf des PHP
-Scriptes soviel RAM zieht. Ich habe testweise den Abruf der
Osnabrücker Adresse nun deaktiviert, da es das letzte war, was zuletzt
am Ticketsystem geändert wurde.
Gestern gab es ja mehrere DB-Fehler, die wohl entstanden, als Stefan
irgendwas machte:
https://p.rrbone.net/paste/vAPmDetc#jC-Rn/qL
vg
Und ein paar pids gekillt.
Wenn was nicht geht auf srv03 nicht wundern.
Nicht einfach neu starten 03 ist nicht dicke an RAM.
Sprich bjo oder mich am besten an
Danke im voraus.
Moin,
ist die Kiste tatsächlich mit 1 IMAP Abruf mehr überfordert 
ist die Kiste tatsächlich mit 1 IMAP Abruf mehr überfordert
tja, das haben wir auch gedacht.
ich habe keine ahnung wie *gut* der PHP code ist, aber er brauchte
gestern sehr viel RAM.
If email piping is not a preferred option for you or if your hosting >
provider does not support it, you may use POP3/IMAP account polling
kannst du die tickets pushen?
es war anscheint der tropfen was alles zu überlaufen brachte,
wir haben dann noch ein paar kleine anpassungen gemacht um weniger RAM
für laufende services zu brauchen (z.b gitlab sidekiq, apache worker,
pids gekillt) so ist die aktuelle lage...
# free -lm
total used free shared buffers
Mem: 2001 1846 154 76 48
-/+ buffers/cache: 1363 637
Swap: 3811 1396 2415
srv03 hat nur 2GB RAM -> https://fr32k.de/pad/p/ffnw_server_hw
ich kann an den srv noch ein paar tunnings vornehmen, z.b unnötige TTY,
services abschalten, kernel tunnings usw... aber schritt für schritt.
> ist die Kiste tatsächlich mit 1 IMAP Abruf mehr überfordert
tja, das haben wir auch gedacht.
ich habe keine ahnung wie *gut* der PHP code ist, aber er brauchte
gestern sehr viel RAM.> If email piping is not a preferred option for you or if your
> hosting >
provider does not support it, you may use POP3/IMAP account polling
> instead. http://osticket.com/wiki/POP3/IMAP_Setting_Guide
kannst du die tickets pushen?
Wie soll der IMAP-Server die Tickets pushen?
es war anscheint der tropfen was alles zu überlaufen brachte,
wir haben dann noch ein paar kleine anpassungen gemacht um weniger
RAM
für laufende services zu brauchen (z.b gitlab sidekiq, apache worker,
pids gekillt) so ist die aktuelle lage...
# free -lm
Das war kein Tropfen, das war eine Talsperre. Es war doch nicht so,
dass das System vorher schon vollkommen am Limit war und dann der
Ticket-Prozess 200MB mehr hatte. Er hat ja stattdessen 4 GB mehr.
srv03 hat nur 2GB RAM -> https://fr32k.de/pad/p/ffnw_server_hw
ich kann an den srv noch ein paar tunnings vornehmen, z.b unnötige
TTY,
services abschalten, kernel tunnings usw... aber schritt für schritt.
Meines Erachtens unnötige Spielerei, weil es das Problem selbst nicht
löst. Wir könnten die Tage 03 mal auf 01 umziehen, dann gibts eh mehr
RAM. Vielleicht frisst der Prozess ja dann 6 GB.
mit einer weiterleitung -> ans ticket system?
Das bringt rein gar nichts!
Dann kannst du Tickets nicht sortieren lassen.
Nach dem Umzug können wir den Cron ja wieder rennen lassen..
Und mit welchem Protokoll? Soll das Ticketsystem selbst per SMTP
lauschen, eingehende Mails annehmen und dann intern verarbeiten, also
quasi all das, was nun ein MTA und ein MDA machen?
vg
Der Cron ist nicht aus, es ist lediglich die Osnabrücker Addi
deaktiviert. Braucht ihr die eigentlich wirklich oder könnte man die
Sachen auch über unsere info@ laufen lassen?
Besser wäre eigenständig, da da manche Anfragen kommen, wo ihr
wahrscheinlich denkt was wollen die denn.
Ich finde es sinvoller!