nicht angemeldet
Moin!
mysql scheint nun deutlich an die grenzen gestossen zu sein. in stosszeiten sind evtl. auch selects von 255/s möglich. jedenfalls knapp. mysql lockte sich anfänglich öfter mal ("in benutzung" lt. phpmyadmin -> bug mit mysql patch beseitigt, mittlerweile scheint apache nicht mehr mit mysql kommunizieren zu können. problem kann nicht eingegrenzt werden, aber irgendwann hat mysql wohl auch seine grenzen....)
Ich weiß ja nicht, was du mit MySQL angestellt hast, aber üblicherweise kommt es mit SELECTs auch in großen Datenmengen am besten klar. 2 Millionen Einträge sind doch nicht wirklich viel.
Wenn deine SELECTs zu lange dauern, könnte das an einem fehlenden, für diese SELECTs passenden Index liegen. Da kann man extrem viel Performance rausholen.
Gegen irgendwelche MySQL-Bugs hilft natürlich ein Update - da du nichts dazu gesagt hast, welche Versionen du hast, kanns auch keine Empfehlung geben, was man dagegen tun kann.
Da du die Frage ursprünglich gestellt hast: Ja, dein Ansatz, alle Daten im Speicher zu halten, ist ziemlich gewagt. Es gibt reichlich Datenbanksysteme auf diesem Planeten, von billig und schnell über kostenpflichtig und für die Aufgabe unzureichend bis hin zu extrem teuer, schnell, sehr mächtig und wahrscheinlich überdimensioniert.
Wenn PHPMyAdmin bzw. Apache mit MySQL keine Verbindung mehr kriegt, dann wird irgendwas kaputtgegangen sein oder sich geändert haben. Bevor ich mir jedenfalls einen komplett neuen Ansatz ausdenke, ohne wirklich Ahnung davon zu haben (deine Verwirrungen um Shared Memory und Semaphoren deuten es an), würde ich mir erstmal überlegen, wie das alte System zu besserer Leistung zu überreden ist.
wieder viel geschrieben, meine fragen kurz zusammengesfasst:
- welche werte müsste ich nun definitiv im apache-kernel erhöhen, die sich auf die anzahl der reinzulegenden werte (arrays) von derzeit 2 Mio beziehen? gibts hier irgendwo verständliche informationen wie das zu handeln ist
Überleg doch mal selbst: 2 Millionen Datensätzt - wie groß ist einer durchschnittlich? Da davon auszugehen ist, dass die Datensätze mindestens mit einem Pointer im Speicher abgelegt werden, und dieser Pointer auf 32-Bit-Plattformen aus 4 Byte bestehen, belegst du _mindestens_ schon mal 8 Megabyte Speicher nur, um ein Minimum an Verwaltungsinformationen abzulegen. Dazu kommt, dass ein Datensatz (du sprachst von "Telefonliste) wohl eher aus 100 Byte denn aus 10 besteht - was prompt einen Speicherbedarf von mindestens nochmal 200 Megabyte nach sich zieht für die reinen Daten (nach einer sehr konservativen Schätzung). Da davon auszugehen ist, dass die Sache mit nur einem Pointer nicht getan ist, bzw. du auf die Art der Speicherverwaltung in PHP nicht genauestens Einfluss nehmen kannst, dürfte der tatsächliche Wert weit darüber liegen. Mit anderen Worten: Du belegst mindestens 256 MB, eher noch 512 MB oder gar 1 GB (je nachdem, ob du nun 100 Byte, 200 Byte oder 400 Byte pro Datensatz verwaltest) an RAM-Speicher nur für die Daten. Hinzu kommt dann noch ein vernünftiger Index, denn obwohl RAM-Zugriffe sehr schnell sind: Irgendwie will man doch eher selten die gesamte Liste linear auslesen.
Wenn es aber um die Performance geht, muss der Server viel RAM haben. Leider ist die Obergrenze für RAM bei derzeitigen Systemen bei 4 GB. Das bedeutet, dass du mindestens ein Viertel des RAM-Speichers mit deinen Daten belegst. Das erscheint mir nicht sehr vorteilhaft. Und es legt die Obergrenze der Datenmenge pro Datensatz auf 2 Kilobyte - dann wären deine 4 GB mit 2 Millionen Datensätzen vollkommen ausgelastet. Ich weiß nicht, wie es mit RAM-Swapping aussieht, aber das ist ganz sicher eine Performancebremse, insbesondere, wenn die falschen RAM-Bereiche ausgelagert wurden.
- ist in meinem fall von dem SHM evtl. komplett abzuraten und vielleicht doch ein "file-cache-system" zu verwenden?
Es wäre sinnvollerweise eine funktionierende Datenbank zu verwenden... :)
- Sven Rautenberg