Sporthoj.com - Online igen

[wdac]

Jo Oracle är en riktigt kraftfull databas ingentvekan om det, men det är inget bra gratis alternativ, om det är sådana programvaror man letar efter.



Inte för att låta snobbig men 30.000 rader är väldigt lite På vv finns det vissa databaser som håller saker över 10 miljoner rader.

de gäller bara Våra egna kunder, sen har vi ju alla andra ISP som hyr DSL uppkoppling av oss så som Glocalnet, Vattenfall, Universial, Phonera med mera.

jag har dålig koll på om hur många kunder som ligger under dessa, 30K är bara Våra egna priv kunder sen har vi alla företags kunder också som ligger på fibernätet.. så de är en hel del mer än 30K totalt sett i vårt system.

EDIT: samt att trafik loggas.

 

[d1ce]

Jag skulle lätt kunna tänka mig att betala en slant för att hänga på SH.

Tror nog att de flesta skulle röra sig vidare till nästa gratisforum. Och inte skulle alla stjärnskott som man får skratta gott åt och med betala för sig

Köp ett par tröjjor istället.

-@

 

[Sep]

Vad är multum?

Jag skulle lätt kunna tänka mig att betala en slant för att hänga på SH.
Även om det inte skulle vara ett krav.

Bra jobbat Swedie

Av ren nyfikenhet kollade jag lite snabbt på deras hemsida och det verkar som en standardversion kostar 15000 dollar, sen 3300dollar för updateringar och support..

Nu är jag ingen databaskung utan en simpel embedded programmerare (eftersom nu alla skriver ut sina titlar ) och har endast pysslat lite med databaser på en kurs och lite hemmapul, men mysql ska nog klara av sporthoj.com utan problem.. Om man jämför så är sporthoj.com ingen stor databas..

Är det inte så enkelt att det är hårdvaran som inte orkar med? Loggar ni någon form av prestanda?

 

[TRoos]

Mysql lämpar sig utmärkt för tabeller med många poster ...
50 - 100 miljoner är inget problem ... i vissa avseenden ´hanterar den
stora datamängder effektivare än både oracle, db2 ms-sql etc .
Jag har jobbat som DBA i 19 år så jag har haft möjlighet att jämföra både
det ena o det andra.

Problemen med SH har nog mer med Konfiguration / tuning , HW systemlogik etc att göra än valet av db-hanterare !

Just my 2 cents !

/Swekat

Om du är så rutinerad borde du väl kunna ge en hjälpande hand och tweaka till det, det vore ju optimalt eftersom du har sådan lång erfarenhet!

 

[Swedie]

Ingen jätte-databas alls. bara 2 gb eller så (ren text, alla bilder ligger som filer på servern).

Det är bara antalet läsningar hela tiden mot databasen, konstant och hela tiden alltid.. osv puh!

så här ser en mtop ut ifrån servern... vad kan ni avläsa?

load average: 6.96, 5.58, 4.61 mysqld 4.1.11-Debian_4sarge7-log up 0 day(s), 5:15 hrs
53 threads: 49 running, 57 cached. Queries/slow: 3.4M/428 Cache Hit: 99.18%
Opened tables: 16.3K RRN: 716.1M TLW: 27.7K SFJ: 95 SMP: 63 QPS: 278

ID USER HOST DB TIME COMMAND STATE INFO
128467 användare... localhost sporthoj 59 Query Sending data SELECT ... FROM thread AS thread INNER JOIN post AS
128456 användare... localhost sporthoj 58 Query Sending data SELECT ... FROM thread AS thread INNER JOIN post AS
128586 användare... localhost sporthoj 39 Query Sending data SELECT ... FROM thread AS thread INNER JOIN post AS
128292 användare... localhost sporthoj 19 Query Sorting resu SELECT ... FROM post AS post WHERE threadid = 84558
128296 användare... localhost sporthoj 8 Query Locked UPDATE post SET parentid = 2812929 WHERE threadid =
128708 användare... localhost sporthoj 8 Query Locked SELECT ... FROM post AS post WHERE threadid = 15446
128627 användare... localhost sporthoj 7 Query Locked SELECT ... FROM post LEFT JOIN thread USING (thread
128653 användare... localhost sporthoj 7 Query Locked SELECT ... FROM post LEFT JOIN thread USING (thread
128696 användare... localhost sporthoj 7 Query Locked SELECT ... FROM post AS post LEFT JOIN user AS user
128713 användare... localhost sporthoj 7 Query Locked SELECT ... FROM post WHERE threadid = 153154 AND vi
128723 användare... localhost sporthoj 7 Query Locked SELECT ... FROM post AS post LEFT JOIN user AS user
128728 användare... localhost sporthoj 7 Query Locked SELECT ... FROM attachment AS attachment LEFT JOIN
128731 användare... localhost sporthoj 7 Query Locked SELECT ... FROM attachment AS attachment LEFT JOIN
128721 användare... localhost sporthoj 6 Query Locked SELECT ... FROM post AS post WHERE threadid = 15449
128729 användare... localhost sporthoj 6 Query Locked SELECT ... FROM thread AS thread LEFT JOIN deletion
128732 användare... localhost sporthoj 6 Query Locked SELECT ... FROM post AS post WHERE threadid = 10220
128733 användare... localhost sporthoj 6 Query Locked SELECT ... FROM post AS post LEFT JOIN user AS user
128736 användare... localhost sporthoj 6 Query Locked SELECT ... FROM post WHERE threadid = 141134 AND vi
128737 användare... localhost sporthoj 6 Query Locked SELECT ... FROM post AS post LEFT JOIN user AS user
128739 användare... localhost sporthoj 6 Query Locked SELECT ... FROM post AS post WHERE threadid = 15371
128740 användare... localhost sporthoj 6 Query Locked SELECT ... FROM attachment AS attachment LEFT JOIN
128742 användare... localhost sporthoj 6 Query Locked SELECT ... FROM attachment AS attachment LEFT JOIN
128743 användare... localhost sporthoj 6 Query Locked SELECT ... FROM attachment AS attachment LEFT JOIN
128745 användare... localhost sporthoj 6 Query Locked SELECT ... FROM attachment AS at

 

[TRoos]

Ingen jätte-databas alls. bara 2 gb eller så (ren text, alla bilder ligger som filer på servern).

Det är bara antalet läsningar hela tiden mot databasen, konstant och hela tiden alltid.. osv puh!

så här ser en mtop ut ifrån servern... vad kan ni avläsa?

Det är väl inget speciellt som går att avläsa.. Men det är ju ständiga selects, som sker när en sidvisning visas.. Kanske skulle det varit så att sidan var cachad på webbservern. Dvs att man inte får färsk information hela tiden utan att det generas varje minut eller något istället det skulle göra otroligt mycket för prestandan. Men det är ju också alltid så att man får tumma på användarvänlighet, prestanda och säkerhet.

Men det är ju trottsallt ett alternativ.

Ett annat alternativ är att systemet genererar ut forumtrådar till html filer. Men allting lagras på samma sätt i databasen. Sen om ett inlägg / tråd ect ändras så generaras dem om. Dvs direkt när någon ska läsa en tråd så är den statisk den är genererad och behöver inget databas anrop utan bara skickas ut av webbservern. Kanske smartare sätt om man vill ha allting "live-update"

 

[swekat]

Om du är så rutinerad borde du väl kunna ge en hjälpande hand och tweaka till det, det vore ju optimalt eftersom du har sådan lång erfarenhet!

Jo .. men sånt tar tid ... först måste programvaran analyseras och sen när man vet HUR den jobbar samt hur DB-designen är uppbyggd¨å kan man sätta
sig ned o identifiera stoppklossar och utföra diverse åtgätrder.

Dock så ser jag i swedies dump att det är mysql 4.x som körs ... en uppgradering till V 5.0 (GA) skulle nog vara på sin plats .. ger en del performancemässigt samt har bättre möjligheter till Tuning ... ev skulle man kunna satsa på att gå ända till 6.0 (Alpha) alternativt 5.2 då man i dessa versioner har stöd för tabellpartitionering vilket är bra då enstaka tabeller innehåller stora mängder poster.
Sen är det ju inte säkert att den bakomliggande programvaran (antar att det är nåt php-hack) tycker om en uppgradering !

/Swekat

Ingen jätte-databas alls. bara 2 gb eller så (ren text, alla bilder ligger som filer på servern).

Det är bara antalet läsningar hela tiden mot databasen, konstant och hela tiden alltid.. osv puh!

så här ser en mtop ut ifrån servern... vad kan ni avläsa?

Swedie ... är mysql configgad att skicka långsamma querys till slowqry.log

I MY.CNF lägg till ...
log-slow-queries=<PATH TILL NÅT BRA STÄLLE>/slowqry.log

Och starta om mysql ... efter ett tag så borde de värsta syndarna dyka upp i denna logg och vi kanske kan gå vidare därifrån o titta på indexeringseffektivitet mm...

mvh

Swekat

 

[Swedie]

I med att forumet är gjort för mysql 4 så stannar jag där. Kanske i framtiden när vB blir skapat för att ta del av MySQL 5's funktion så kan uppgraderingen genomföras.

Slow-queries-loggningen är inaktiverad just nu. Men det är när det blir mycket avancerade queries med olika variabler från diverse personliga inställningar som det kan bli långa laddningstider som även påverkar alla andra som vill göras queries mot databasen.

 

[xyx]

Nu är jag ingen DBA, utan en sån där vämjelig generalist inom området, men dock:
Om det inte redan görs, så är väl en av de första sakerna att kolla upp om din MySQL använder sig av Query Cache och sen se till att den är rätt konfigurerad.
Detta i kombination med ett lyft till senaste 5.0/5.1 borde iaf ge en lite förbättring.

 

[Swedie]

XCache är installerat. Innan XCache installerades började det bli segt redan runt 500 online.

 

[HanneZ]

2927471 Mysql lämpar sig utmärkt för tabeller med många poster ...
50 - 100 miljoner är inget problem ... i vissa avseenden ´hanterar den
stora datamängder effektivare än både oracle, db2 ms-sql etc .
Jag har jobbat som DBA i 19 år så jag har haft möjlighet att jämföra både
det ena o det andra.

Problemen med SH har nog mer med Konfiguration / tuning , HW systemlogik etc att göra än valet av db-hanterare !

Just my 2 cents !

/Swekat

 

[Meltingfire]

Nu gissar jag vilt, men jag antar att restora-backupen tar < 1h om man har gjort en dump av databasen. Sedan så har du väl säkerligen valt att köra diverse grejer under vB för att återbygga olika "egna indexeringar" som vB kör dvs inte databas-index, varav troligen deras egna sökindexet var det tunga jobbet.

Dock behövs du ju inte vBs egna sökindex för fritextsökning utan i nyare vB så kunde man slå om det till MySQLs fritext (utan för den delen förstöra vBs egna index). Tror tom den är rekommenderad, men är inte hundra.

vB är känt för att orka med många fler miljoner användare och besökare än vad sporthoj har, så jag tror i detta fallet är det väl hårdvaran som inte räcker till eller strular. Men att köpa lite nya servrar kan ju inte vara allt för dyrt. Låt säga man pyntar en hundring så blir man "supermedlem" på forumet och det går till hårdvara eller liknande. Som "supermedlem" får man större inbox, garage, etc you name it.

Inte för att vara snobbig eller så (som någon sa ) men förövrig återställde vi en MSSQL databas på 126GB mitt i förra arbetsveckan, tog 2h totalt varav DB-checken tog mesta delen av tiden Självklart ett nattjobb. *gäsp* Så jag vet vilket pain in the ass DB-krasher är

Men min chef har nog rekord i DB-krasher, tog 1 dag att återställa en backup från band varav ett helt oljebolag praktiskt taget stod stilla

 

[xyx]

XCache är installerat. Innan XCache installerades började det bli segt redan runt 500 online.

XCache cachear väl php-opcodes, inte SQL förfrågningarna?

 

[TRoos]

I med att forumet är gjort för mysql 4 så stannar jag där. Kanske i framtiden när vB blir skapat för att ta del av MySQL 5's funktion så kan uppgraderingen genomföras.

Slow-queries-loggningen är inaktiverad just nu. Men det är när det blir mycket avancerade queries med olika variabler från diverse personliga inställningar som det kan bli långa laddningstider som även påverkar alla andra som vill göras queries mot databasen.

Du menar UPDATE's ? det är ju bara då man får parameterlistor och på INSERT. SELECT och DELETE bör ju oftast inte ta mer än 1,2.

 

[Roger_Soderblom]

Jag hade inte tänkt att lägga mig i diskussionen, men det finns ju en mängd sätt att tweaka på, som har uppkommit tidigare i tråden.

Memcach kan dock vara intressant att använda sig av för att få ner mängden läsningar från databasen.

http://www.danga.com/memcached/

problemet som uppstår då är ju dock är det som är cachat aktuellt?
men det kan man ordna vid skrivningar till databasen.

 

[Swedie]

Låt säga man pyntar en hundring så blir man "supermedlem" på forumet och det går till hårdvara eller liknande. Som "supermedlem" får man större inbox, garage, etc you name it.

Inte för att vara snobbig eller så (som någon sa ) men förövrig återställde vi en MSSQL databas på 126GB mitt i förra arbetsveckan, tog 2h totalt varav DB-checken tog mesta delen av tiden Självklart ett nattjobb. *gäsp* Så jag vet vilket pain in the ass DB-krasher är

Men min chef har nog rekord i DB-krasher, tog 1 dag att återställa en backup från band varav ett helt oljebolag praktiskt taget stod stilla

Det är inte pengar i sig jag vill ha. Jag vill inte ta betalt av någon på SH för att hålla igång sajten, iaf inte så länge jag har annonser till vänster. De betalar nog för att kunna åtminstone ta kostnaden av en som tar på sig jobbet o hackar sig igenom filer osv.

 

[xyx]

Jag hade inte tänkt att lägga mig i diskussionen, men det finns ju en mängd sätt att tweaka på, som har uppkommit tidigare i tråden.

Memcach kan dock vara intressant att använda sig av för att få ner mängden läsningar från databasen.

http://www.danga.com/memcached/

problemet som uppstår då är ju dock är det som är cachat aktuellt?
men det kan man ordna vid skrivningar till databasen.

Tänkte också föreslå memcached. Problemet är väl dock att det kräver anpassningar av php-koden? Misstänker att alla SQL-bunden kod inte finns samlad på ett eller några ställen, vilket kan göra det till ett hästjobb.

MySQLs Query Cache är inte alls lika smart, men kan kanske funka bra om förhållandet mellan läsningar och skrivningar till databasen är stort nog.

 

[Swedie]

2927698 XCache cachear väl php-opcodes, inte SQL förfrågningarna?

Finns det alltså liknande program för MySQL?

Vore det inte fel att ha en cache på php-sidan samtidigt som på mysql-sidan? kan inte informationen bli rätt felaktig ibland då?

 

[Meltingfire]

Är det inte databasens uppgift att cache de mest populära frågorna?

Jag konfigurerade inte upp våran MySQL sist jag körde vB, i och med att jag inte har koll på debian eller linux för den delen. (MS-nörd)

Men följande scenario upplevdes iaf:

Vid en omstart av servern så tog den ca halva minnet på då 1GB, sedan började den cacha upp allt resterande minne till php/mysql. Då körde vi bara mysql rakt upp och ner samt phpaccelerator.
Blev först osäker på om det var för lite minne på burken så vi slängde in en gig till och då visade sig samma fenomen igen.
Vid närmare undersökning såg vi att php/mysql tog över allt minne till cache, sedan om en applikation behövde det så släppte cachen det direkt.

Alltså låg vi och alltid använda 100% minne och 0% swap alla tider på dygnet och minnet utnyttjades optimalt.

Han som konfigurerade vårt system kontaktade dig för ett tag sedan (Mattias B., aka fnord)

 

[xyx]

Finns det alltså liknande program för MySQL?

Vore det inte fel att ha en cache på php-sidan samtidigt som på mysql-sidan? kan inte informationen bli rätt felaktig ibland då?

Query Cache är en inbyggd funktion i MySQL 4/5/6.

Mig veterligen så finns det ingen risk för konflikt mellan dessa två saker då de cachear olika saker i olika skeden.
XCache cachear den kompilerade php-koden så att vi fortare kan kan komma till den punkt då en fråga ställs mot databasen, och sen då http-servern ska få sidan den ska spotta ut.

MySQLs Query Cache sparar resultaten på de senaste SELECTs som gjorts fram tills dess att databasen uppdateras. Därför kan den vara effektiv om det görs relativt många trådvisningar för varje nytt inlägg i en tråd.

Nu vet jag inte vilka andra saker som är gjorda för databasen och det finns folk här som kan dessa saker betydligt bättre än vad jag kan, men i lighthttpd-dokumentationen finns en grundläggande genomgång av MySQL-trimning för en webapplikation:
http://trac.lighttpd.net/trac/wiki/Docs:PerformanceFastCGI#tuning-the-database

Siffrorna stämmer säkert inte för vad sh.com behöver.

Tror jag ska bege mig in på grundare vatten igen...