• Willkommen im Forum „Tintenzirkel - das Fantasyautor:innenforum“.
 

Hilfe! Was legt unser Forum lahm?

Begonnen von Maja, 02. November 2016, 18:25:37

« vorheriges - nächstes »

0 Mitglieder und 2 Gäste betrachten dieses Thema.

Maja

Zitat von: Sprotte am 03. November 2016, 21:14:24
@Maja, was ist mit den Teamcountern? Sollen wir die auch erst einmal entfernen? Nur zur Sicherheit?
Die Teamcounter sind aus Sicht unseres Servers nur kleine Bildchen, die über das <img>-Tag eingebunden werden. Vor allem werden sie nur dann abgerufen, wenn jemand genau die Seite in dem Thread aufruft, in der diese Bilder gezeigt werden - anders als die Counter, die zum einen die Ausführung eines Scripts auf unserem Server erfordern, zum anderen in jedem einzelnen Beitrag der jeweiligen Mitglieder angezeigt werden. Und wir haben dieses Jahr nochmal ein Dutzend Teilnehmer mehr als im vergangenen Jahr, das kann also tatsächlich einen Unterschied machen.

Ich schaue jetzt, ob sich die CPU-Last schon sichtbar verändert hat, rechne aber nicht mit klaren Ergebnissen vor morgen - dafür sind die Ausfälle immer zu unvorhersehbar aufgetreten.
Niemand hantiert gern ungesichert mit kritischen Massen.
Robert Gernhardt

Sprotte

#46
21:39 Seite erstellt in 219.892 Sekunden mit 15 Abfragen.
21:48 Seite erstellt in 538.619 Sekunden mit 14 Abfragen.

Shin

Seite erstellt in 490.382 Sekunden mit 14 Abfragen.
"The universe works in mysterious ways
But I'm starting to think it ain't working for me."

- AJR
"It's OK, I wouldn't remember me either."        
- Crywank          

Miezekatzemaus

ZitatSeite erstellt in 181.595 Sekunden mit 13 Abfragen.
Ich glaube, die Counter können wir damit ausschließen. :-\

Eben hatte ich auch so einen Riesenbatzen wie Sprotte und Shin, den habe ich aber vergessen zu kopieren.

Valkyrie Tina

Zitat von: Miezekatzemaus am 03. November 2016, 21:49:56
ZitatSeite erstellt in 181.595 Sekunden mit 13 Abfragen.
Ich glaube, die Counter können wir damit ausschließen. :-\

Eben hatte ich auch so einen Riesenbatzen wie Sprotte und Shin, den habe ich aber vergessen zu kopieren.

Hier das gleiche, Forum brauchte ca. 5 Minuten zum Laden.

Maja

Ich denke, damit sollte die Unschuld unserer Counter erwiesen sein. Ich habe die Signaturen jetzt wieder eingeschaltet.
Niemand hantiert gern ungesichert mit kritischen Massen.
Robert Gernhardt

Maubel

Ebenso,

aber mir ist gerade aufgefallen, dass ich seit Tagen keine Emails mehr mit Threadbenachrichtigungen erhalten habe. Sind die während des NaNo's ausgeschaltet (weil überwältigend viele) oder könnte da was nicht stimmen?

Erdbeere

Bei mir war das Gleiche, und dann hat das Forum gar nicht mehr geladen. Ich bekam eine Error-Meldung wegen Zeitüberschreitung beim Laden, dauerte insgesamt gute 10 Minuten. Ich habe währenddessen auf anderen Seiten gesurft, aber daran kann es ja wohl kaum liegen.

Blaurot


Maja

Zitat von: Maubel am 03. November 2016, 21:56:30
aber mir ist gerade aufgefallen, dass ich seit Tagen keine Emails mehr mit Threadbenachrichtigungen erhalten habe. Sind die während des NaNo's ausgeschaltet (weil überwältigend viele) oder könnte da was nicht stimmen?
Nein, mit denen ist eigentlich alles in Ordnung. Der Server verschickt die Mails ordnungsgemäß, da habe ich gerade nachgeschaut, und es kommen auch keine Bouncenachrichten. Ich hoffe, wir sind nicht wieder auf irgendwelchen Sperrlisten gelandet ...
Niemand hantiert gern ungesichert mit kritischen Massen.
Robert Gernhardt

Maja

#55
@Volker
Da ich gerade am Rechner war, während der Server abgerauscht ist, habe ich top ausgeführt, um zu sehen, ob Prozesse als wartend aufgeführt sind. Das nicht, aber MySQL verbrauchte mal smakkelig 102% CPU-Power.


top - 22:05:31 up 6 days,  7:49,  1 user,  load average: 1.75, 1.64, 2.14
Tasks: 213 total,   1 running, 212 sleeping,   0 stopped,   0 zombie
%Cpu(s): 24.0 us,  2.5 sy,  1.0 ni, 72.5 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:  16777216 total, 12266380 used,  4510836 free,        0 buffers
KiB Swap:  8388608 total,   120472 used,  8268136 free. 11291036 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
  604 mysql     20   0 2302188  98492   5244 S 102.0  0.6 726:37.88 /usr/sbin/mysqld
20119 root      20   0   19952   1676   1068 R   1.6  0.0   0:00.63 top
20177 www-data  30  10  494276  21132   4576 S   1.3  0.1   0:00.04 /usr/sbin/apache2 -k start
18869 www-data  30  10  501824  41668  20936 S   1.0  0.2   0:05.64 /usr/sbin/apache2 -k start
19495 www-data  30  10  498588  35680  14996 S   0.7  0.2   0:02.40 /usr/sbin/apache2 -k start
19588 www-data  30  10  498284  27468  10364 S   0.7  0.2   0:01.84 /usr/sbin/apache2 -k start
19777 www-data  30  10  504396  40604  17620 S   0.7  0.2   0:01.65 /usr/sbin/apache2 -k start
19936 www-data  30  10  499032  28232  10384 S   0.7  0.2   0:01.36 /usr/sbin/apache2 -k start
20170 www-data  30  10  494624  21276   4660 S   0.7  0.1   0:00.09 /usr/sbin/apache2 -k start
18921 www-data  30  10  498520  25872   8612 S   0.3  0.2   0:03.62 /usr/sbin/apache2 -k start
19911 www-data  30  10  494624  22656   5972 S   0.3  0.1   0:00.61 /usr/sbin/apache2 -k start
20038 www-data  30  10  494632  21428   4784 S   0.3  0.1   0:00.21 /usr/sbin/apache2 -k start
20130 www-data  30  10  494632  21412   4780 S   0.3  0.1   0:00.16 /usr/sbin/apache2 -k start
32716 root      30  10  491984  33296  17080 S   0.3  0.2   0:44.98 /usr/sbin/apache2 -k start
    1 root      20   0   33324   2292   1320 S   0.0  0.0   0:17.81 init
    2 root      20   0       0      0      0 S   0.0  0.0   0:00.00 [kthreadd/124021]
    3 root      20   0       0      0      0 S   0.0  0.0   0:00.00 [khelper/124021]
    4 root      20   0       0      0      0 S   0.0  0.0   0:00.00 [rpciod/124021/0]
    5 root      20   0       0      0      0 S   0.0  0.0   0:00.00 [rpciod/124021/1]
    6 root      20   0       0      0      0 S   0.0  0.0   0:00.00 [rpciod/124021/2]
    7 root      20   0       0      0      0 S   0.0  0.0   0:00.00 [rpciod/124021/3]
    8 root      20   0       0      0      0 S   0.0  0.0   0:00.00 [rpciod/124021/4]
    9 root      20   0       0      0      0 S   0.0  0.0   0:00.00 [rpciod/124021/5]
   10 root      20   0       0      0      0 S   0.0  0.0   0:00.00 [rpciod/124021/6]
   11 root      20   0       0      0      0 S   0.0  0.0   0:00.00 [rpciod/124021/7]
   12 root      20   0       0      0      0 S   0.0  0.0   0:00.00 [rpciod/124021/8]
   13 root      20   0       0      0      0 S   0.0  0.0   0:00.00 [rpciod/124021/9]
   14 root      20   0       0      0      0 S   0.0  0.0   0:00.00 [rpciod/124021/1]
   15 root      20   0       0      0      0 S   0.0  0.0   0:00.00 [rpciod/124021/1]
   16 root      20   0       0      0      0 S   0.0  0.0   0:00.00 [rpciod/124021/1]
   17 root      20   0       0      0      0 S   0.0  0.0   0:00.00 [rpciod/124021/1]
   18 root      20   0       0      0      0 S   0.0  0.0   0:00.00 [rpciod/124021/1]
   19 root      20   0       0      0      0 S   0.0  0.0   0:00.00 [rpciod/124021/1]
   20 root      20   0       0      0      0 S   0.0  0.0   0:00.00 [rpciod/124021/1]
   21 root      20   0       0      0      0 S   0.0  0.0   0:00.00 [rpciod/124021/1]
   22 root      20   0       0      0      0 S   0.0  0.0   0:00.00 [rpciod/124021/1]
   23 root      20   0       0      0      0 S   0.0  0.0   0:00.00 [rpciod/124021/1]
   24 root      20   0       0      0      0 S   0.0  0.0   0:00.00 [rpciod/124021/2]
   25 root      20   0       0      0      0 S   0.0  0.0   0:00.00 [rpciod/124021/2]
   26 root      20   0       0      0      0 S   0.0  0.0   0:00.00 [rpciod/124021/2]
   27 root      20   0       0      0      0 S   0.0  0.0   0:00.00 [rpciod/124021/2]
   28 root      20   0       0      0      0 S   0.0  0.0   0:00.00 [nfsiod/124021]
  179 root      20   0   19424    576    488 S   0.0  0.0   0:00.42 upstart-udev-bridge --daemon
  198 root      20   0   49212    700    696 S   0.0  0.0   0:00.05 /lib/systemd/systemd-udevd --daemon
  214 root      20   0  316656   2652   2412 S   0.0  0.0   0:07.26 smbd -F
  268 root      20   0  308704    576    484 S   0.0  0.0   0:00.00 smbd -F
  271 root      20   0  316656    796    592 S   0.0  0.0   0:06.13 smbd -F


Wenn es das nächste mal hängt, mache ich ss -pan | fgrep ':3306 ' - den Befehl konnte ich nur erst wieder nachsehen, als der Server wieder lief ...


EDIT
Während der nächsten Downtime abgefragt:
root@lvps92-51-133-22:~# ss -pan | fgrep ':3306 '
tcp    LISTEN     0      0                      *:3306                  *:*      users:(("mysqld",604,10))
tcp    LISTEN     0      0                      *:3306                  *:*      users:(("mysqld",604,10))

Niemand hantiert gern ungesichert mit kritischen Massen.
Robert Gernhardt

Pandorah

Oh Mann, Maja. Ich will dich einfach mal eben knuddeln, dass du neben dem NaNo jetzt auch noch das hakelige Forum an der Backe hast. Danke, dass du dich darum kümmerst. :knuddel: Und danke an alle, die helfen.

Volker

Zitat von: Maja am 03. November 2016, 22:18:59

%Cpu(s): 24.0 us,  2.5 sy,  1.0 ni, 72.5 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
  604 mysql     20   0 2302188  98492   5244 S 102.0  0.6 726:37.88 /usr/sbin/mysqld


Du hast den "M"-vServer mit 4 vCores? Das würde dann erklären, warum MySQL (auf 1 vCore) voll ausgelastet ist, der Server (mit 4 vCores) aber nur zu 1/4

MySQL muss da optimiert werden. Hast Du Dir die Ausgaben von dem Skript mal angeschaut, den ich Dir zugesandt habe?
Die Einstellungen müssten dann in /etc/mysql/my.cnf gemacht und MySQL neu gestartet werden.

Was Du auch noch machen kannst, wäre die möglichen Locks 'rauszunehmen bzw. die Aufgaben besser zu verteilen - jeweils im [mysqld] Abschnitt

max_connections = 500
innodb_flush_log_at_trx_commit = 0
innodb_read_io_threads = 64
innodb_write_io_threads = 64
innodb_thread_concurrency = 8


Es kann einfach sein, dass das Forum nun an die Grenzen der klassischen Default-Einstellungen stößt - und dann das Forum schlicht auf die Datenbank warten muss. Dann müssen die Buffer und Entkopplungen optimiert/vergrößert werden.

Maja

Zitat von: Volker am 04. November 2016, 00:00:32
Du hast den "M"-vServer mit 4 vCores? Das würde dann erklären, warum MySQL (auf 1 vCore) voll ausgelastet ist, der Server (mit 4 vCores) aber nur zu 1/4
Ich habe den "Expert"-Server, ein Modell, das es so nicht mehr gibt, seit sie die Servermodelle umgestellt haben. Sollen sein 8 GB RAM, 4 vCores (CPU-Kerne à 1.500 Gigaherz). Das kann also hinkommen mit deiner Einschätzung.

ZitatMySQL muss da optimiert werden. Hast Du Dir die Ausgaben von dem Skript mal angeschaut, den ich Dir zugesandt habe?
Die Einstellungen müssten dann in /etc/mysql/my.cnf gemacht und MySQL neu gestartet werden.
Bei mir ist irgendwie nichts angekommen, kannst du mir das nochmal schicken?

Ich überlege allerdings, nach dem Nano auf das nächstgrößere Servermodell umzuziehen, weil ich das Gefühl habe, wir könnten auch ein bisschen mehr Performance durchaus verkraften.
Niemand hantiert gern ungesichert mit kritischen Massen.
Robert Gernhardt

Volker