Vergangene Nacht war ich mit 'nem Kumpel damit beschäftigt, eine Homepage zu debuggen, die auf einem neuen Server einfach nicht mehr funktionieren wollte. Manche Seiten waren weiß, ein paar wenige Seiten funktionierten dagegen - und im PHP-Log war zu sehen, daß der Speicherverbrauch die festgelegte 16-MB-Grenze gesprengt hat, weshalb sich PHP zum Abbruch der Skriptausführung gezwungen sah.

Die Frage war: was ist mit der Homepage nach der Migration plötzlich passiert? Auf dem alten Server ging sie auch mit dem 16M-Speicherlimit. Die Antwort ist hierbei ganz einfach und leider auch ein bißchen erschreckend - der neue Server ist ein 64-Bit-System. Auch die PHP-Installation ist die 64-Bit-Variante.

Der Speicherverbrauch der problematischen Homepage hat sich eindeutig meßbar im Schnitt verdoppelt. Eigentlich muß das nicht unbedingt der Fall sein, bloß weil der Prozessor von 32 Bit auf 64 Bit "hochgeschnellt" ist, aber scheinbar geht die 64-Bit-Version von PHP etwas verschwenderisch mit dem Speicher um.

Ich kann mir gut vorstellen, daß intern sämtliche Ganzzahlen auf 64-Bit-Integer festgelegt sind (anstatt dies je nach Bedarf niedriger anzusiedeln), und dazu kommen dann noch sämtliche Pointer, die zur Adressierung des größeren Adressraums wahrscheinlich standardmäßig ebenso 64-Bit sind. Allein diese Werte verdoppeln daher schon einmal ihren Speicherbedarf.

Da die betreffende Homepage eine recht komplizierte, objektorientierte Architektur hat, ist wohl der Ärger im Rahmen dieser Migration vorprogrammiert gewesen - nur geahnt hat es keiner.

Ich hab jedenfalls mal wieder was dazugelernt - insbesondere daß es wohl erforderlich ist, auf einem modernen 64-Bit-System auch tiefer in die Tasche für mehr RAM zu greifen. Ebenso ist es unvermeidlich, spendabler mit dem PHP-Memory-Limit umzugehen. Wenn das alles nicht hilft, muß man wohl leider wieder auf ein 32-Bit-System zurückgreifen.

Derzeit fallen mir gehäuft und regelmäßig "Einbruchsversuche" auf einer, von mir erstellten, Homepage auf, da diese Versuche Ausnahmefehler verursachen, welche mich automatisch mit allen Details über E-Mail informieren.

Diese Attacken kommen jeweils von unterschiedlichen Servern, verfolgen aber immer dasselbe Muster:

• Eine URL wird als GET-Parameter an "meine" Homepage übergeben
• "Meine" Homepage mag das nicht schlucken, bricht ab und schickt mir ne Email

Ich hab mir ein paar dieser "injizierten URLs" angeschaut und es sind immer Textdokumente, welche PHP-Code repräsentieren:

Es ist offensichtlich ein PHP-basiertes Internetvirus, welches die Weiten des Internets durchsucht, um "kleine Dummheiten" von PHP-Programmierern zu finden.

Das Virus spekuliert offenbar auf folgenden Sachverhalt:

Führt das PHP-Skript auf dem anzugreifenden Server Benutzereingaben aus?

PHP 5 weist nicht nur aufgeräumte Sprachergänzungen in puncto Objektorientierung, sondern auch erhebliche Probleme im Speicher-Management auf.

Der sogenannte "garbage collector", welcher sich für das Aufräumen unbenötigter Daten, Ressourcen und Objekte verantwortlich zeichnet, versagt unter gewissen Umständen seinen Dienst.

Dieser Artikel erläutert nicht nur dieses Problem anhand eines Beispiels, sondern stellt auch eine Lösung hierzu vor.

PHP und Sicherheit ist ein wichtiges Thema - insbesondere durch den hohen Verbreitungsgrad des "PHP: Hypertext Preprocessor"'s. Es ist eine nette, offenbar einfach zu erlernende Skriptsprache, welche den Webentwickler recht flott Ergebnisse erzielen läßt. Bei aller Einfachheit, bzw. bei allem Komfort, liegt es am Entwickler, gewisse Sicherheitsvorkehrungen an seinen Skripten vorzunehmen, um nicht unerfreuliche Bekanntschaft mit Hackern und "Skriptkiddies" zu machen.