Beiträge von ice-breaker

    nicht böse sein Alex, aber das sind die gleichen Antworten wie immer ;)
    Schuld beim Kunden, Probleme bei Plugins des Gameservers und mein Favorit "bei anderen geht es doch auch".



    Ich habe gerade leider keine Zeit den Thread zu suchen, aber da hast du selbst mal bestätigt, dass z.B. um 0 Uhr morgens die IO-Last auf Grund vieler Cronjobs, Log-Rolls usw. verschiedener Kunden die IO-Last des Wirts steigen kann und somit Auswirkungen auf andere Kunden haben könnte.
    Wenn solche Probleme aber eben tagsüber auftreten, dann kann man meistens nicht schnell genug reagieren und dies loggen, es fällt dann z.B. kraZey auf wenn er gerade spielt oder jemand anderes spielt und bis er nachgeschaut hat, ist das Problem schonwieder weg, betrifft aber alle seine Mitspieler - und ist somit höchstwahrscheinlich unabhängig vom Routing.
    Und genau das Gleiche habe ich auch bereits mehrmals festgestellt, nein es ist kein Gameserver sondern ein Webserver, das selten der Request bei IO-Operationen mal eine Sekunde hängt, da es ein Dev-System ist, mach ich mir aber nicht die Mühe das Problem zu Suchen, da erstmal ich ja der Böse unerfahrene bin, der den Fehler verursacht.




    Wie gesagt, nicht gegen dich oder Netcup persönlich ;)
    Aber es ist eben die gleiche Standardleier wie immer, ihr werdet zwar bei den meisten Fällen Recht haben, dass der Kunde Mist gebaut hat, aber es trifft eben nicht immer zu. Und kraZey hat seinen Aussagen zu Folge schon einmal das gesamte System neu gemacht, das müsste also ziemlich viele Fehler ausschließen.

    Zitat von kraZey;36887

    Ich kann es nocheinmal erwähnen: Der Server kriegt lags, wenn PB-Screens gemacht werden, wenn Logs aktuallisiert werden und wenn alle Kerne schlagartig belastet werden (und daran kann ich rein garnichts tun).


    richtig, und das ist auch der Grund warum vServer nicht für Gameserver geeignet sind, denn deine Nachbarschaft kann dir mit solchen Aktionen das System für bestimmte Dinge mit hohen Echtzeitanforderungen (wie Gameserver) unbrauchbar machen.
    Auch wenn Netcup das nicht zugeben will, denn einige Kunden würden dann sicherlich nicht mehr hierher kommen und vServer buchen ....


    Wenn ein anderer Node auf dem Host eben sporadisch die IO-Last in die Höhe treibt hast du eben verloren. I/O-Scheduling ist in der Virtualisierung nur rudimentär vorhanden. Du wirst dann aber trotzdem von allen darauf hingewiesen, dass du auf einmal nur deine CPU-Leistung nutzen kann, die dir zusteht, denn der Grund ist ja viel einfacher, als zuzugeben, dass es auch an der von Netcup eingesetzten Software liegen kann.

    buffers/cache steigt bei mir nicht, sondern sinkt nur, wenn der freie Speicher ausgeht. Breche ich unter 20 ab (größer 0) springt der Wert aber wieder zurück. Nach dem Test ist wieder alles wie zuvor.


    Scheinbar geht es nicht bei allen, eventuell kernel spezifisch?

    Code
    2.6.36.4-vs2.3.0.36.39-netcup #1 SMP Wed Mar 9 07:18:38 UTC 2011 x86_64 GNU/Linux

    Du solltest dir noch im klaren sein, dass Video-Streaming sehr viel Bandbreite benötigt, du wirst also bald auf einem High-Traffic Node landen bei dem du deutlich weniger Bandbreite zur Verfügung hast, ob das dann noch für die Menge deiner Zuschauer reichen wird ist von vielen Faktoren abhängig.


    Edit: own3d.tv haut ~1MBit/s raus, da wirst du auf einem High-Traffic-Node aber schnell an deine Grenzen stoßen ....

    Die suhosin session encryption gehört jedoch zur Suhosin Extension, der kann man gerne kontrovers gegenüberstehen, der Suhosin Patch läuft aber absolut transparent und schützt wirklich nur vor katastrophalen Fehlern.
    Also hast du nur ein Problem mit der Extension, nicht mit dem Patch ;)


    Um es nochmal klarer zu formulieren: Der Suhosin Patch schützt dich vor Programmierfehlern im PHP-Kern oder Extensions, die z.B. sonst zu Buffer-Overflows führen, nicht mehr und nicht weniger. Und diesen Schutz willst du wirklich nicht aufgeben, es seiden du spielst gerne mit dem Feuer. Es gibt zwar noch Dinge die der Suhosin Patch weiter implementiert, aber die machen nichts kaputt.

    Ich glaube du verstehst den Sinn des Suhosin Patches nicht ;)
    Ersteinmal müssen wir den Suhosin Patch von der Suhosin Extension unterscheiden. Der Suhosin Patch ist dafür da die PHP-Runtime sicherer zu machen, die Extension erlaubt darüber hinaus noch einige nette Sicherheitsfeatures zu aktivieren.



    Bei dir greift, wie im Log zu sehen, der Suhosin-Patch und schützt dich vor einem Overflow in PHP, der katastrophale Auswirkungen haben könnte. Das willst du keinesfalls deaktivieren. Der Suhosin-Patch hat seine Existenzberechtigung und sollte in jedes PHP eingebunden wird. Man sehe sich nur mal den Month of PHP Bugs vor Jahren an, fast alle Fehler waren in einem PHP mit Suhosin Patch nicht mehr vorhanden.


    Und nein, der Suhosin Patch lässt sich nicht deaktivieren, er wird fest in den PHP Core einkompiliert.

    du solltest eventuell darüber nachdenken dir einen vServer mit mehr Ram zuzulegen, nicht nur, dass dein vServer swappt, nein, der Swap wird auch schon fast komplett ausgenutzt, ein paar MB mehr und alles fliegt dir um die Ohren, weil kein Prozess mehr "Arbeitsspeicher" allokieren kann

    Zitat von fyaa;35946

    Ich weiß gar nicht, wieso man SQLite verwenden möchte, wenn man nicht sehr ressourcenbeschränkt ist.


    Weil es "einfacher" ist?
    Ich habe mal für nen Kunden eine Anwendung geschrieben, deren Datenbankanforderungen minimalst waren, da habe ich dann auf die MySQL-Datenbankbank verzichtet mit dem Vorteil, dass die Installation kinderleicht war: man musste nur die ganzen Dateien per FTP hochladen und fertig, keine Datenbankverbindung einstellen, keine SQL-Datei importieren oder auch keinen Installer den man Schritt für Schritt durchgehen musste.

    Zitat von christian;35765

    SQLite ist also für einfache Aufgaben mehr als geeignet, da sich aber alles in einer Datei abspielt muss die gesamte Datenbank bei Zugriffen gesperrt werden. Wenn also mehrere Nutzer zur gleichen Zeit auf die Datenbank zugreifen wird es mit steigendenden Zugriffszahlen immer langsamer.


    das ist schon lange nicht mehr so, seit Version 3 kann eine SQLite-Datenbank auch von mehreren Prozessen gleichzeitig genutzt werden.
    Einzig Schreiben kann nur ein Prozess gleichzeitig [1], aber das wäre auch genauso mit MyISAM unter MySQL.
    Solange du keine riesigen Concurrency-Anforderungen hast sollte SQLite deine Anforderungen locker erfüllen können ;)


    Zitat von christian;35765

    Bei einzelnen Zugriffen ist aber SQLite in vielen Fällen schneller als MySQL.


    unterschreibe ich so nicht.
    Das ist eine pauschale Aussage, die per Definition somit schon falsch ist, es wird sicherlich Anwendungsbereiche geben bei denen es so ist, aber auch genug bei denen andersherum ist.


    Zitat von christian;35765

    Ich denke mit MySQL werde ich nicht viel falsch machen können.


    Solange du InnoDB mit Transaktionen verwendest dann nicht ;)



    [1] http://www.sqlite.org/faq.html#q5

    (keine offizielle Aussage):
    Auf Grund der immensen Serverbelastung dieser ganzen Miesen-Chat-Scripte lässt eigentlich kein Webhoster diese zu.


    Mit Diensten wie pusher.com kannst du dir jedoch einen echten Realtime-Chat bauen der auf deinem Webhosting-Account keine Serverleistung beansprucht, da pusher.com dies übernimmt, soetwas ist dann immer erlaubt.

    Zitat von chitypo;34721

    Wo holt ihr nur die zahlen her. stand in der computer bild?:D


    Nein, aber große Benchmarkserien zu neuen Prozessoren ;)
    Und wenn der Prozessor mit HT eingeschaltet und HT ausgeschaltet nur eine gewisse Differenz hat ....


    Zitat von [netcup] Alex;34724

    Ein HT Kern ist nicht ein Kern. HT bezeichnet eine Technik wie Kerne eines Prozessors für Rechenprozesse verwendet werden.


    Dem bin ich mir bewusst, aber diese werden von Betriebssystemen als logische Kerne abgebildet, deshalb die Aussage eines logischen HT Kerns.


    Zitat von [netcup] Alex;34724

    Die HT Technik steigert die Effizienz eines Prozessors nachweislich. [...] Ein Prozessor mit HT Technik arbeitet effektiver bzw. effizienter als ein Prozessor ohne HT Technik. Einen "Leistungszuwachs" im Sinne der Geschwindigkeit des Prozessors kann es daher also auch nicht geben sondern "nur" (wobei die Verbesserung erheblich ist) eine effizienter Rechenprozessabarbeitung durch entsprechende Verteilungs- und Zuteilungstechniken seitens des Controllers innerhalb der CPU.


    Da zeigen die meisten Benchmarks, sowohl theoretische als auch praktische i.R. aber ganz anderes (Vergleich SMT vs. ohne SMT)

    aber niemals dem Trugschluss unterliegen die HT-Kerne seien so effizient wie normale, i.R. sind die lächerlich schwach: unter 10% Leistung eines echten Kerns

    Kann mich mjablonski nur anschließen, die Java-VM sollte ausreichend groß dimensioniert werden, und ein Jetty kann z.B. auch schonmal ordentlich Ram fressen.


    Quercus? Kann man das mitlerweile wirklich produktiv betreiben? Vor einem halben Jahr habe ich meine Anwendungen damit mal ausprobiert und ich bin auf Unmengen PHP-Funktionen gestoßen, die in Quercus noch nicht implementiert waren.

    Zitat von T0mcat;33642

    Abgesehen von den gelegentlich auftretenen IO-Wait Problemen, habe ich keinen Grund mich zu beschweren.


    geht mir genauso, aber bei einem Gameserver macht sich solch ein IO-Wait eben gleich richtig negativ bemerkbar ;)
    Und ich vermute persönlich auch, dass das öfter die Probleme sind, also nur bei denen die nicht auch noch Teamspeak, Apache und und und auf dem vServer laufen lassen.

    Zitat von T0mcat;33638

    Du bist bisher der einzige der sich über solche Probleme beschwert.


    äh nein, solche Themen gibt es alle paar Wochen, schau mal in den GameServer-Bereich ;)
    Von daher denke ich persönlich schon lange, dass es an Netcup liegt, soviele können es einfach nicht falsch machen, die Leistung von Netcup mag zwar zu 99% wirklich topp sein, aber bei denen die einen Gameserver betreiben fällt dann eben das 1% wo es miserabel läuft auch auf, nicht so wie wenn man nur nen Apache usw. auf dem vServer hätte.