N
ninguno
Tripel-As
kann mich der meinung von lordlamer nur anschliessen, finde auch dass so grosse logfiles unbrauchbar sind
theton
Bitmuncher
@lordlamer: Vielleicht solltest du mal den kompletten Thread lesen. Ich lasse das Programm nicht immer ueber die grosse Datei laufen. Habe ich nie behauptet. Ich habe immer wieder mal neue kleinere Input-Dateien, die, nachdem sie geparsed wurden, an die Output-Datei angehaengt werden, so dass die Output-Datei (logischerweise) immer groesser wird (mittlerweile halt 5.2 GB). Wuesste also nicht, was ich da cachen sollte. Auf den Servern, auf denen die Input-Dateien erzeugt werden laeuft logrotate und ich nehme halt immer die letzten Logs (zumindest, die die ich brauche, warum ich nicht alle benutze, will ich jetzt hier nicht ausfuehren, hab aber meiner Gruende), schiebe sie auf den Statistik-Server und lasse dort mit meinem Parser die referer-Eintraege entfernen. Der Output wird danach an die grosse Datei angehaengt und genau damit hatte PHP Probleme.
@ninguno: Ob du grosse Logdateien als unbrauchbar betrachtest ist ja durchaus deine Sache, aber ich will nunmal eine grosse Logdatei haben und habe auch meine Gruende dafuer.
@Wolfgang_1: Ich hatte es auch noch mit Perl versucht, aber auch dort trat das gleiche Problem auf. Es konnten nicht mehr in die Output-Datei geschrieben werden, sobald diese 2GB erreicht hatte.
@ninguno: Ob du grosse Logdateien als unbrauchbar betrachtest ist ja durchaus deine Sache, aber ich will nunmal eine grosse Logdatei haben und habe auch meine Gruende dafuer.
@Wolfgang_1: Ich hatte es auch noch mit Perl versucht, aber auch dort trat das gleiche Problem auf. Es konnten nicht mehr in die Output-Datei geschrieben werden, sobald diese 2GB erreicht hatte.
Zuletzt bearbeitet:
lordlamer
Haudegen
sorry aber ich sehe das mit dem cachen immernoch so. du könntest ja mal erklären wieso du immer wieder die referrer neu weg speicherst. ich denke auch das sich bei dir eine datenbank vielleicht lohnen würde. die verwaltet die daten ja viel besser. was genau schreibst du den alles weg vom referer und was wertest du den genau aus?
mfg frank
mfg frank
W
Wolfgang
Foren Gott
avaurus schrieb:sorry, das ist total unlogisch.
Da kann ich mich nur anschließen!
Nach einem diesbezüglichen Test hatte ich ja gefragt.
Die Antwort dazu blieb aus.
Wenn dd das kann, dann kann auch perl das.
Für die IO-Geschichten verwendet perl nämlich die c-librarys!
Wie hast du das denn versucht?
Notfalls hättest du das sogar in eine pipe nach dd schreiben können.
Klingt irgendwie sehr unlogisch.
Welche Fehlermeldung hat denn perl ausgespuckt?
Gigantische Textdateien zu parsen, ist auch wahrhaftig nicht die Lösung.
Sowas regelt man möglichst schon deshalb atomar, weil du schnell mal in eine Race Condition gerätst, die du nicht immer vorhersehen kannst.
Bei solch langlaufenden Prozessen ist die Wahrscheinlichkeit ziemlich hoch.
Gruß Wolfgang
Zuletzt bearbeitet:
theton
Bitmuncher
Ich entferne aus verschiedenen access_log-Dateien verschiedener Webserver die kompletten Referer-Eintraege . Diese Referer-Eintraege werden nirgendwo gespeichert, sondern einfach nur entfernt. Die auf diese Weise "gesaeuberten" access_logs werden dann an eine einzige access_log-Datei angehaengt um auf diese Weise alle access_logs aller bei uns stehenden Webserver zu archivieren, falls sie doch nochmal gebraucht werden (was extrem unwahrscheinlich ist). Ich sehe dabei nichts, was man cachen koennte, vor allem, weil es immer wieder neue Dateien sind und nicht, wie du offenbar vermutest immer wieder die gleichen. Die Nummerierung, die ich verwende hat damit zu tun, von welchem unserer Server die Logs kommen.
Ausserdem kann auf diese Art mit einem einzigen Durchlauf unseres Statistik-Tools eine einzige Statistik fuer alle Webserver zusammen erstellt werden. Das Tool kommt leider nicht mit mehreren Dateien klar, was erst geaendert wird, wenn einer unserer Entwickler mal die Zeit findet es entsprechend zu korrigieren. Solange muss es halt mit einer Datei gehen. Mein Vorgaenger ging naemlich bei der Einfuehrung dieses Tools davon aus, dass es eh in unserer Firma nur einen Webserver geben wird. Mittlerweile sind es doch einige mehr geworden (an meinem Script kann man ja sehen, dass ich es mittlerweile mit 126 access_logs zu tun habe) und Chef will auf dieses Tools nicht verzichten. Also lag es an mir erstmal einen Workaround zu finden.
Ausserdem kann auf diese Art mit einem einzigen Durchlauf unseres Statistik-Tools eine einzige Statistik fuer alle Webserver zusammen erstellt werden. Das Tool kommt leider nicht mit mehreren Dateien klar, was erst geaendert wird, wenn einer unserer Entwickler mal die Zeit findet es entsprechend zu korrigieren. Solange muss es halt mit einer Datei gehen. Mein Vorgaenger ging naemlich bei der Einfuehrung dieses Tools davon aus, dass es eh in unserer Firma nur einen Webserver geben wird. Mittlerweile sind es doch einige mehr geworden (an meinem Script kann man ja sehen, dass ich es mittlerweile mit 126 access_logs zu tun habe) und Chef will auf dieses Tools nicht verzichten. Also lag es an mir erstmal einen Workaround zu finden.
W
Wolfgang
Foren Gott
Hallo
@theton
Die internen Bedingungen sind schon etwas seltsam, aber gut das ist ja eventuell eine andere Sache. Wenngleich ich schon sagen muss, dass das ein recht seltsames tool sein muss, was im I/O nur mit einer Datei klarkommt.
Aber mich interessiert die immernoch offene Frage, was denn perl für einen Fehler produziert hat?
Welche perl - Version hast du denn installiert/verwendet?
Ich finde das nämlich mehr als seltsam.
Interessiert mich einfach, warum das nicht gehen soll, mit diverse andere shell- tools aber doch?!?
Die Browserscriptsprache php und perl haben ja nun wirklich nichts miteinander zu tun.
Gruß Wolfgang
PS Ja, ich habe von php-cli gehört, aber das ist doch nur ein Notbehelf und hat auch nix mit perl zu tun.
@theton
Die internen Bedingungen sind schon etwas seltsam, aber gut das ist ja eventuell eine andere Sache. Wenngleich ich schon sagen muss, dass das ein recht seltsames tool sein muss, was im I/O nur mit einer Datei klarkommt.
Aber mich interessiert die immernoch offene Frage, was denn perl für einen Fehler produziert hat?
Welche perl - Version hast du denn installiert/verwendet?
Ich finde das nämlich mehr als seltsam.
Interessiert mich einfach, warum das nicht gehen soll, mit diverse andere shell- tools aber doch?!?
Die Browserscriptsprache php und perl haben ja nun wirklich nichts miteinander zu tun.
Gruß Wolfgang
PS Ja, ich habe von php-cli gehört, aber das ist doch nur ein Notbehelf und hat auch nix mit perl zu tun.
W
Wolfgang
Foren Gott
avaurus schrieb:
Hallo
Dann habe ich mich wohl falsch ausgedrückt.
php ist eine eine serverseitige Scriptsprache, wobei dabei das http-Protokoll bedient wird, indem diese in html eingebettet wird.
Insofern war der Begriff auf den Client bezogen.
Im Grunde genommen hat man die webbasierenden Fähigkeiten von perl genommen und daraus eine einfache in HTML eingebettet Scriptsprache entwickelt. Das wurde dann php.
Perl war ja ursprünglich auch nicht für die Verwendung im CGI gedacht, hat dann aber dadurch zunehmend an Popularität gewonnen.
In erster Linie ist perl - im Gegensatz zu php - als ein mächtiges Werkzeug für die Textverarbeitung und Datenbankschnittstelle in der Shell entwickelt worden.
Unter jeder Linuxdistri werkeln standardmäßig etliche Perlscripte, um das System am Laufen zu halten.
Dass sowas auch für die CGI-Schnittstelle verwendbar ist, war klar und die Popularität logische Konsequenz mit aufkommenden Webservern.
Als Fazit bleibt zu sagen, dass perl all die webbasierten Fähigkeiten von PHP beinhaltet und darüber hinaus noch weit mehr für die Admin - commandline bietet.
Es gibt nichts, was php kann und perl nicht könnte.
Aber eine Menge was mit perl geht, aber nicht gleichermaßen mit php.
Sorry, sollte kein Statement für perl werden, sondern mehr erklären was ich meinte.
Die Frage warum perl keine Files größer 2GB erzeugen konnte, ist nebst Fehlermessage weiterhin ungeklärt.
Gruß Wolfgang
EDIT
@avaurus hast du deinen Beitrag gerade gelöscht?
Warum?
Irgendwie stehe ich nun etwas aus dem Zusammenhang gerissen da.
Zuletzt bearbeitet:
A
avaurus
°°°°°°°°°°°°°
weil offtopic.
