Warum so viele gettimeofday Anrufe?


11

Warum führt die PHP / Apache-Kombination so viele gettimeofdaySystemaufrufe durch? Auch wenn sie schnell sind, ist jeder Anruf ein Anruf, der berücksichtigt werden sollte.

Nur eine kurze strace -c -p [apache2 process id], gibt Folgendes:

Process 22294 detached
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 98.52    0.010000          51       196           poll
  1.48    0.000150           0     20752           gettimeofday
  0.00    0.000000           0        94         7 read
  0.00    0.000000           0        48           write
  0.00    0.000000           0        96        32 open
  0.00    0.000000           0        75           close
  0.00    0.000000           0         6           chdir
  0.00    0.000000           0       766           time
  0.00    0.000000           0         2           chmod
  0.00    0.000000           0        56        10 access

Diese 20.000 Anrufe machen mir Sorgen. Möchte jemand etwas Licht ins Dunkel bringen?


Java ist noch schlimmer ...
Nils

Was macht dein Programm?
Michael Hampton

1
Ich kann das "Warum" nicht beantworten, aber kennen Sie stackoverflow.com/questions/7266813/… und access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_MRG/… ? Der Systemaufruf wird normalerweise dem Benutzerbereichscode ("vsyscall") zugeordnet, sodass der Overhead erheblich reduziert wird.
The-Wabbit

1
Der Graf sollte dich nicht beunruhigen. Die Umfrage hat nur 200 Anrufe, nutzt aber über 98% der Zeit. Sie können zur normalen Strace-Ausgabe wechseln, dann werden Sie sehen, was Apache tut (verlangsamt dies erheblich).
ott--

Antworten:


4

Gettimeofday wird hauptsächlich von Apache aufgerufen, um Einträge in Debug-Dateien zu protokollieren. Einige Module verwenden auch gettimeofday. Also kein Grund zur Sorge.

BEARBEITEN: Ich habe einige PHP-Quellcode-Grabungen durchgeführt und die folgenden Ergebnisse erzielt: Die meisten zeitbezogenen PHP-Funktionen verwenden die Systemzeit. Da sie die Systemzeit verwenden, wird gettimeofday häufig aufgerufen. Wenn Sie also die Anrufe reduzieren möchten, reduzieren Sie Ihre zeitbezogenen Funktionen.

Ich muss allerdings bemerken, dass andere Funktionen auch gettimeofday-Anrufe tätigen. Wenn Sie beispielsweise php_session_start verwenden, ruft dies (manchmal abhängig von einigen Parametern wie bei einer neuen Sitzung, ...) php_combined_lcg auf, wodurch wiederum lcg_seed aufgerufen wird, wenn kein Startwert festgelegt ist Holen Sie sich eine Pseudozufallszahl. Und lcg_seed ruft gettimeofday an. Behalte dies im Kopf.


Aber was ist, wenn mein CLI-PHP-Skript auch viele gettimeofday-Aufrufe ausführt? Stimmt etwas mit meinem PHP nicht? (Verwendet dh date () oder mktime () diese Funktionen, wenn ich keinen Zeitstempel als Parameter gebe?)
Gekkie

Habe ein bisschen gesucht und meine Antwort bearbeitet
timmeyh

Danke ... Ich denke, ich muss nur mit all diesen Anrufen leben. :)
Gekkie

Wenn Sie xdebuginstalliert haben, kann es auch ein Nebenprodukt davon sein.
B00MER

1

Ich habe festgestellt, dass die Aktivierung des PHP-Moduls xdebug dazu führt, dass strace mehrere gettimeofdayAnrufe meldet .


1

Jeder Prozess, für den ein Zeitstempel erforderlich ist, ruft gettimeofday auf, sodass es schwierig ist zu wissen, ob er normal ist oder nicht.

Zum Beispiel kann es sich um ein Modul handeln, das ein Protokoll erstellt, ein Modul, das die Uhrzeit überprüft. Um zu wissen, warum es so viele gettimeofday gibt, deaktivieren Sie Apache-Module, die für den Aufruf von gettimeofday verantwortlich sein könnten. Es gibt möglicherweise zu viele Schreibvorgänge in zahlreiche Protokolldateien, die sich in verschiedenen Ordnern befinden.

  • Deaktivieren Sie die üblichen Verdächtigen wie mod_log_debug oder mod_status
  • Laden Sie die Konfiguration von Apache neu
  • strace
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.