animal skrev:varför inte ha ett Python-script som läser in förstasidan 3 ggr/min och loggar misslyckade anslutningsförsök med tillhörande felmeddelanden? Ska jag göra ett?

För att det ökar belastningen på servern, och därmed riskerar att göra problemen större.

nallen skrev:

animal skrev:varför inte ha ett Python-script som läser in förstasidan 3 ggr/min och loggar misslyckade anslutningsförsök med tillhörande felmeddelanden? Ska jag göra ett?

För att det ökar belastningen på servern, och därmed riskerar att göra problemen större.

Åas kan det ju kanske hjälpa till att hitta felet fortare. PHP-loggen ger mej lite felmeddelanden numera, men inget vettigt alls. Eller vad sägs om det här:

Kod: Markera allt

[22-Jun-2012 03:02:50] PHP Fatal error:  Allowed memory size of 33554432 bytes exhausted (tried to allocate 9182535 bytes) in Unknown on line 0

SQL-loggen är fortf tom så jag måste gjort den fel på något vis.

animal, please if you wish, jag tar gärna emot den hjälp jag kan få för google vill inte hjälpa mej och något är fel i min sql-loggning.

Värt att lägga märke till är att det oftast räcker att starta om apachen när Generalen är här.

weasley skrev:

nallen skrev:

animal skrev:varför inte ha ett Python-script som läser in förstasidan 3 ggr/min och loggar misslyckade anslutningsförsök med tillhörande felmeddelanden? Ska jag göra ett?

För att det ökar belastningen på servern, och därmed riskerar att göra problemen större.

Åas kan det ju kanske hjälpa till att hitta felet fortare. PHP-loggen ger mej lite felmeddelanden numera, men inget vettigt alls. Eller vad sägs om det här:

Kod: Markera allt

[22-Jun-2012 03:02:50] PHP Fatal error:  Allowed memory size of 33554432 bytes exhausted (tried to allocate 9182535 bytes) in Unknown on line 0

SQL-loggen är fortf tom så jag måste gjort den fel på något vis.

animal, please if you wish, jag tar gärna emot den hjälp jag kan få för google vill inte hjälpa mej och något är fel i min sql-loggning.

Värt att lägga märke till är att det oftast räcker att starta om apachen när Generalen är här.

Har du lagt märke till vilken status kod man får tillbaka på en standard HTTP-GET när generalen är framme? 200? 500?

nallen skrev:

animal skrev:varför inte ha ett Python-script som läser in förstasidan 3 ggr/min och loggar misslyckade anslutningsförsök med tillhörande felmeddelanden? Ska jag göra ett?

För att det ökar belastningen på servern, och därmed riskerar att göra problemen större.

Skitsnack. Det är 29 kB * 3 * 60 * 24 = typ 1.3 MB/dag – ingenting i sammanhanget.

weasley skrev:/.../

Åas kan det ju kanske hjälpa till att hitta felet fortare. PHP-loggen ger mej lite felmeddelanden numera, men inget vettigt alls. Eller vad sägs om det här:

Kod: Markera allt

[22-Jun-2012 03:02:50] PHP Fatal error:  Allowed memory size of 33554432 bytes exhausted (tried to allocate 9182535 bytes) in Unknown on line 0

SQL-loggen är fortf tom så jag måste gjort den fel på något vis.

animal, please if you wish, jag tar gärna emot den hjälp jag kan få för google vill inte hjälpa mej och något är fel i min sql-loggning.

Värt att lägga märke till är att det oftast räcker att starta om apachen när Generalen är här.

Se http://public.e-lspb.appspot.com/backend/public/get_af_fetch_errors för logg i JSON-format (CORS är självklart aktiverat). Jag pollar startsidan 3 ggr/min.

Om du inte har JSON View eller motsvarande installerat i Chrome, skynda att installera – https://chrome.google.com/webstore/detail/chklaanhfefbnpoihckbnefhakgolnmc.

Edit: Deadline för HTTP-GET är satt till 15 sek, om du undrar över att du får många "error_tag: 'Error: Timeout (DownloadError)'"-meddelanden.

Stötte på generalen flera gånger 22:26 - 22:27, tills jag gav upp att komma in på forumet...

animal skrev:

nallen skrev:För att det ökar belastningen på servern, och därmed riskerar att göra problemen större.

Skitsnack. Det är 29 kB * 3 * 60 * 24 = typ 1.3 MB/dag – ingenting i sammanhanget.

Det är inte mängden bytes som är avgörande här. Utan alla transaktioner med processortid och diskrassel somm behövs för att verkställa http frågan.

plåtmonster skrev:

animal skrev:

nallen skrev:För att det ökar belastningen på servern, och därmed riskerar att göra problemen större.

Skitsnack. Det är 29 kB * 3 * 60 * 24 = typ 1.3 MB/dag – ingenting i sammanhanget.

Det är inte mängden bytes som är avgörande här. Utan alla transaktioner med processortid och diskrassel somm behövs för att verkställa http frågan.

Skitsnack. En vanlig sidvisning i någon random tråd ligger på ~150 kB och omkring 6-8 ocachade anrop och tar typ 500-800 ms i anspråk för databassökingar och dyl. AF har 30-40' sidvisningar/dag.

Det scriptet hämtar hem är en av de absolut enklaste och vanligaste sidorna (startsidan) i 1 anrop, sidan lär garanterat vara kontinuerligt memcachad och tar bara omkring 150 ms att generera. Så jämför 150 ms * 4 320 = 648 s med 500 ms * 30 000 = 15 000 s, en belastningsökning på << 5 %. Då har vi ändå inte tagit hänsyn till a) att scriptet i stor utsträckning belastar servern när den ändå inte har något för sig (typ omkring kl. 01-08) och b) varken läser in bilder, stylesheets, Google Analytics, JQuery, m.m.

Jaha. Det enda som är nytt är att jag hittar en 503. Service unavailable. Idéer?

weasley skrev:Jaha. Det enda som är nytt är att jag hittar en 503. Service unavailable. Idéer?

Om du slår på loggning fullt ut i LAMP-servern kanske du kan se om det finns någon korrelation mellan t.ex. antal sidvisningar/timme och längden på intervallen mellan då General Error kickar in inom samma tidsspann. Det är bara att samla in data över ett par dagar och lägga dina magiska mattefingrar på underlaget.

Kan man se vilka variabler General Error korrelerar med mer noggrannt så blir det nog betydligt lättare att identifiera var i PHP-koden någon klåpare har lagt in "side effects"/läckor och åtgärda bristen.

Om du lägger upp en otrafikerad kopia av AF på någon extern/likvärdig server så kan jag lägga in ett till script som pollar kopian (för att jämföra felfrekvensen). Har spontant svårt att tänka mig att felet skulle uppstå helt random oavsett belastning (med reservation för att jag inte är någon expert på PHP).

Om det visar sig att felet faktiskt uppstår helt random kanske det är något cron-job (eller motsvarande) eller modulen som cachar PHP-koden som läcker? Mycket som kan gå fel när man bygger skitsystem i PHP.

Edit: Jag körde ab med 1000 anrop (100 simultant) c:a 15 sekunder innan det "General Error" som kickade in c:a kl. 22:26:30–22:33:00 idag. (Ska inte göra det fler gånger, ville bara testa.)

Jag igen. Ett hett tips för att jobba med stora mängder "messy data" är Google Refine. Skitbra för att automagiskt filtrera ut och normalisera de dataset man faktiskt är intresserad av.

animal skrev:Edit: Jag körde ab med 1000 anrop (100 simultant) c:a 15 sekunder innan det "General Error" som kickade in c:a kl. 22:26:30–22:33:00 idag. (Ska inte göra det fler gånger, ville bara testa.)

En sån grej vore kanske vettig att testa nattetid omkring 3-4 på natten då det oftast är extremt lugnt, frågan är bara om apachen måste startas om manuellt eller om kanske en cron kan sköta det.

Förresten, det borde vara möjligt att skriva script som kollar om apachen behöver omstart och i så fall gör det.

Miche skrev:/.../

Förresten, det borde vara möjligt att skriva script som kollar om apachen behöver omstart och i så fall gör det.

Precis vad phpBB behöver – fler ful-hack!

animal skrev:Precis vad phpBB behöver – fler ful-hack!

Jo, så länge man är beroende av en kod som fungerar dåligt så är det svårt att lösa problemet utan fulhack. Jag har räddat många företag med fula lösningar tills de fått den riktiga lösningen, de har liksom inte råd att stå stilla.

Miche skrev:Jag har räddat många företag med fula lösningar

Exempel?

Fundering.. man kan skriva ett skript som laddar hem sidor allt fortare tills man får General-1040. Så kan man se när det triggas? (obs för loggfilerna)

Apachen startas om varje natt när databasbackupen tas.

Så vitt jag förstått behöver den startas om när Generalen intagit fortet så den skulle ju behöva startas om oftare så länge Generalen anfaller med sina 1040 man!

Miche skrev:Så vitt jag förstått behöver den startas om när Generalen intagit fortet så den skulle ju behöva startas om oftare så länge Generalen anfaller med sina 1040 man!

Oftast klarar den sej utan omstart, men ibland är Generalen lite för ihärdig, då går jag in och startar om manuellt.

Att behöva scripta att den startar om flera ggr/dag är ju barockt.

Har du/ni sett nåt samband mellan att folk gör nåt särskilt på forumet och hängningarna. Sökfunktionen är ju en nästan självklar misstänkt.

weasley skrev:PHP-loggen ger mej lite felmeddelanden numera, men inget vettigt alls. Eller vad sägs om det här

Kod: Markera allt

PHP Fatal error:  Allowed memory size of 33554432 bytes exhausted (tried to allocate 9182535 bytes) in Unknown on line 0

9 MiB i en allokering... nån som kan mer PHP får svara på om det är normalt och rimligt.
Är det normalt att PHP påstår att den inte vet vad det är den exekverar? Jag tänker på "[...] in Unknown on line 0".

weasley, kommer det där felet varje gång eller var det nåt tillfälligt?

nallen skrev:Har du/ni sett nåt samband mellan att folk gör nåt särskilt på forumet och hängningarna. Sökfunktionen är ju en nästan självklar misstänkt.

Och postningar tycker jag mig ha märkt. Kanske framför allt ändringspostningar.

Jag har också reagerat på långa svarstider vid postningar, ja.
Men det borde inte vara nån databas-mässigt tung operation tycker (gissar) jag.
Sökningar och indexuppdateringar känns mer misstänkta tycker min humla.

nallen skrev:Har du/ni sett nåt samband mellan att folk gör nåt särskilt på forumet och hängningarna. Sökfunktionen är ju en nästan självklar misstänkt.

weasley skrev:PHP-loggen ger mej lite felmeddelanden numera, men inget vettigt alls. Eller vad sägs om det här

Kod: Markera allt

PHP Fatal error:  Allowed memory size of 33554432 bytes exhausted (tried to allocate 9182535 bytes) in Unknown on line 0

9 MiB i en allokering... nån som kan mer PHP får svara på om det är normalt och rimligt.
Är det normalt att PHP påstår att den inte vet vad det är den exekverar? Jag tänker på "[...] in Unknown on line 0".

weasley, kommer det där felet varje gång eller var det nåt tillfälligt?

Även om PHP hör till de sämsta av tänkbara skitproduker så får man väl anta att PHP är begåvat nog att allokera minne i batchar, inte on-demand för varje enskild operation? Isåfall är det knappast uppseendeväckande att allokera 9 MB. Batch-vis allokering skulle väl också kunna förklara varför PHP inte kan ge någon exakt referens till källan i form av modul+kodrad?

Förvisso kan det vara så, jag tolkade det som att det där meddelandet motsvarade ett enda malloc()-motsvarande anrop i koden, men jag har som sagt ingen koll på PHP.
Det finns anledningar till att dynamisk minneshantering oftast är förbjuden i de system jag jobbar med.

nallen skrev:/.../

Det finns anledningar till att dynamisk minneshantering oftast är förbjuden i de system jag jobbar med.

Va nyfiken jag blir... Vad är det du jobbar med egentligen? Trodde du var någon sorts ljudtekniker som pluggade in sladdar i högtalare om dagarna, men jag verkar ha varit fel ute.