Det senaste forumavbrottet!
Det senaste forumavbrottet!
Kimmelie skrev:Vilket operativsystem gäller det? Är det Linux så kan en 'PAE kernel' klara 16 GB RAM för 32-bit. Logrotate brukar användas för att rotera loggarna.
Det medger iofs mer minne i servern men inte mer minne per process.
Det senaste forumavbrottet!
Hm!
Intressant...
Så, att skripta fram något som...
Skulle det vara något så hojta, jag har viss tid tillgängligt.
@ lillmupp, sidan nallen hänvisar till påtalar besvär med logrotate.
Intressant...
Så, att skripta fram något som...
- tar fram de fem segaste sökningarna, sparar de annorstädes
rullar error-loggen
flushar
Skulle det vara något så hojta, jag har viss tid tillgängligt.
@ lillmupp, sidan nallen hänvisar till påtalar besvär med logrotate.
Det senaste forumavbrottet!
När maskinkravet är på 4 GB RAM minne för att hantera ett forum så är något galet. Usenet åstadkom i stort sett liknande funktion med en Intel Pentium 200 MHz med 64 MB ramminne*.
Nu består phpBB av mycket kod som inte låter sig hanteras av en person. Utan det är något grundläggande galet. Så fixen i dagsläget är mer lappa och laga. "quickfix".
Nu består phpBB av mycket kod som inte låter sig hanteras av en person. Utan det är något grundläggande galet. Så fixen i dagsläget är mer lappa och laga. "quickfix".
- plåtmonster
- Inlägg: 15480
- Anslöt: 2010-03-23
- Ort: Nära havet
Det senaste forumavbrottet!
Alltså, jag har uttryckt mej konstigt verkar det som.
Det som är problemet är att en tabell som heter nåt phpbb_tjafs_template_xxx är enorm och när den genomsöks tar det jättelång tid vilket är det som syns i loggen och varje entry i loggen tar upp all html som visas på den sida som råkat ut för en slow_query.
Det är alltså inte storleken på loggfilen som är problemet. Om jag har gett er det intrycket är jag hemskt ledsen och vill härmed dementera eventuella sådana påståenden. Problemet är tabellen jag nämnde, vilken är den som renderar denna enorma loggfil. Men det är tabellen som man gör en förfrågan till ("hämta den här sidan!") och som sedan tar väldigt lång tid på sej att svara och skicka tillbaka svaret ("ok, här har du en massa html").
Jag är usel på att förklara sånt här. Det blir väldigt lätt fel när jag försöker beskriva något som har med datorers komplexitet att göra. Översättningen från bilden jag har i huvet till den text som hamnar på skärmen blir inte rätt. Det är bra att ni ställer frågor!
nallen, jag funderar på att huppa mysqld men precis som med Generalen så löser det egentligen inte problemet utan tar bara bort symptomen. Men det är en framkomlig väg att gå, ja.
Det som är problemet är att en tabell som heter nåt phpbb_tjafs_template_xxx är enorm och när den genomsöks tar det jättelång tid vilket är det som syns i loggen och varje entry i loggen tar upp all html som visas på den sida som råkat ut för en slow_query.
Det är alltså inte storleken på loggfilen som är problemet. Om jag har gett er det intrycket är jag hemskt ledsen och vill härmed dementera eventuella sådana påståenden. Problemet är tabellen jag nämnde, vilken är den som renderar denna enorma loggfil. Men det är tabellen som man gör en förfrågan till ("hämta den här sidan!") och som sedan tar väldigt lång tid på sej att svara och skicka tillbaka svaret ("ok, här har du en massa html").
Jag är usel på att förklara sånt här. Det blir väldigt lätt fel när jag försöker beskriva något som har med datorers komplexitet att göra. Översättningen från bilden jag har i huvet till den text som hamnar på skärmen blir inte rätt. Det är bra att ni ställer frågor!
nallen, jag funderar på att huppa mysqld men precis som med Generalen så löser det egentligen inte problemet utan tar bara bort symptomen. Men det är en framkomlig väg att gå, ja.
Det senaste forumavbrottet!
plåtmonster skrev:Nu består phpBB av mycket kod som inte låter sig hanteras av en person. Utan det är något grundläggande galet. Så fixen i dagsläget är mer lappa och laga. "quickfix".
Jag håller helt med. Någonstans i all röra som är phpbb3 finns det såna här logiska buggar. Men de är ju svåra att hitta när man sitter i testmiljö, utan dyker upp när koden provas i skarpt läge. Sen kan de ju bero på plattform (slackware linux i det här fallet) vilket gör dem än mer svårfunna.
Den gamle Generalen avhjälptes genom att öka värdet för syn-timeout. Det ska man inte behöva göra tycker jag. Inte på en maskin med 4GB RAM för ett forum med 6k användare.
Någonstans bland all kod är det någonting som gör att SQL-frågorna tar ovettigt lång tid. Är någon intresserad av att hjälpa mej ta reda på det så skicka gärna ett PM. Annars får det, om ett tag (jag har lite andra saker jag vill prova först), bli nallens lösning. En quick-and-dirty hardcore omstart av sql-en helt enkelt.
Bara så alla vet; OMM jag väljer nallens lösningsförslag så kommer forumet ligga nere en liten stund under den tiden. Jag kommer naturligtvis meddela här i RNS om när och hur, ifall jag väljer den vägen.
Det senaste forumavbrottet!
Det är ju värt att testa nallens förslag, prova under de tider som Titti föreslagit, kanske 04.00 då det oftast är väldigt lugnt.
Det senaste forumavbrottet!
Menar du "phpbb_styles_template_data"? Verkar som om det är fler som har problem med att just den här tabellen växer sig makalöst stor.weasley skrev:Det som är problemet är att en tabell som heter nåt phpbb_tjafs_template_xxx är enorm och när den genomsöks tar det jättelång tid vilket är det som syns i loggen och varje entry i loggen tar upp all html som visas på den sida som råkat ut för en slow_query.
Verkar dock inte som att den har någon viktig funktion.
SQL-kommandot:
- Kod: Markera allt
DELETE FROM phpbb_styles_template_data
- Mellanvärld
- Inlägg: 1243
- Anslöt: 2010-11-28
- Ort: Göteborg
Det senaste forumavbrottet!
Tackar och bockar för konkreta tips!
Ska lägga även detta på minnet för eventuellt framtida bruk.
Ska lägga även detta på minnet för eventuellt framtida bruk.
Det senaste forumavbrottet!
Forumtråden som Mellanvärld länkar till tycks innehålla två konkreta och "riktiga" korrigeringar.
https://www.phpbb.com/community/viewtopic.php?f=46&t=1887385#p11414225 antyder att man någonstans kan välja att inte lagra templates (vad de nu är mallar för) i databasen alls.
https://www.phpbb.com/community/viewtopic.php?f=46&t=1887385#p13149757 sätter om tabellen till att inte tillåta duplicerade rader genom att göra om ett fältpar till primärnyckel.
Vilken lösning som är bäst vet jag inte - båda ter sig fullt rimliga i mina ögon.
I en maskin med gott om minne och om mallarna i fråga inte är så många/stora, så skulle jag gissa att det är effektivare att inte låta databasen tugga på dem alls. Att hålla några MB i diskcachen är ju inte ens 0,1% av primärminnet och om de används ofta så borde de bli kvar i cachen. Någon senare post antyder att det kan ge problem med ägarskapet för filerna, men det borde vara lätt fixat på en dedicerad maskin.
https://www.phpbb.com/community/viewtopic.php?f=46&t=1887385#p11414225 antyder att man någonstans kan välja att inte lagra templates (vad de nu är mallar för) i databasen alls.
https://www.phpbb.com/community/viewtopic.php?f=46&t=1887385#p13149757 sätter om tabellen till att inte tillåta duplicerade rader genom att göra om ett fältpar till primärnyckel.
Vilken lösning som är bäst vet jag inte - båda ter sig fullt rimliga i mina ögon.
I en maskin med gott om minne och om mallarna i fråga inte är så många/stora, så skulle jag gissa att det är effektivare att inte låta databasen tugga på dem alls. Att hålla några MB i diskcachen är ju inte ens 0,1% av primärminnet och om de används ofta så borde de bli kvar i cachen. Någon senare post antyder att det kan ge problem med ägarskapet för filerna, men det borde vara lätt fixat på en dedicerad maskin.
Det senaste forumavbrottet!
JOR skrev:@ lillmupp, sidan nallen hänvisar till påtalar besvär med logrotate.
Ja, och mitt citat kunde klippts kortare för jag kommenterade PAE och 16GB
Det senaste forumavbrottet!
Kimmelie skrev:Vilket operativsystem gäller det? Är det Linux så kan en 'PAE kernel' klara 16 GB RAM för 32-bit. Logrotate brukar användas för att rotera loggarna.
Visserligen så kan PAE paging använda mer än 4G fysiskt minne, men det hjälper inte om man bara har en process, då linjära addressutrymmet är lika stort som utan PAE. Det finns ju dessutom 64-bitars Linux versioner som borde vara bättre om det beror på minnsebrist.
Angående SQL-problemen så vet jag inte så noga. Låter mest som om någon inställning i SQL-servern är felsatt. Det borde inte skapas enorma filer som hela tiden växer.
Det senaste forumavbrottet!
weasley, hur gick det med det här? Jag har inte sett till general Error på länge och jag kan inte säga att jag saknar honom, men jag är lite nyfiken på vad som fixade det hela.
Det senaste forumavbrottet!
Det funkar ju åtminstone och även om det händer någon gång då och då att sidan inte kan hittas så är det ju bara att uppdatera så brukar det fungera igen så det känns ju lugnt.
Ursäkta en okunnig fråga, vad gör SYN-timeout (okej, jag hade kunnat googla... jag har inte så bra pejl på såna delar av SQL), vilken är normala tiden och vad har du satt för tid nu?
Ursäkta en okunnig fråga, vad gör SYN-timeout (okej, jag hade kunnat googla... jag har inte så bra pejl på såna delar av SQL), vilken är normala tiden och vad har du satt för tid nu?
Det senaste forumavbrottet!
SYN-timeout har inget med SQL att göra direkt... det är en del av TCP.
Jag tänker inte berätta mer eftersom redan denna information gör forumet åtkomligare för elaka överbelastningsattacker.
http://en.wikipedia.org/wiki/Transmissi ... l_Protocol
Jag tänker inte berätta mer eftersom redan denna information gör forumet åtkomligare för elaka överbelastningsattacker.
http://en.wikipedia.org/wiki/Transmissi ... l_Protocol
Det senaste forumavbrottet!
weasley skrev:Ett riktigt fulhack alltså.
Jaja, funkar det så funkar det.
Återgå till Regler, nyheter och synpunkter