Linux langzame mediafiles-server

[Verwijderd]

Hallo jongens,

Ik heb wat problemen met mijn linux bakken (redhat 9).

Deze servers dienen als fileservers voor media files (vaak .wmv en .swf files van tussen de 1 en 10MB). Ik lever deze files aan via HTTP.

Webserver is apache 1.x.

Nu heb ik als hardware config: AMD 64 3000+, 1GB ram, 4x 150 GB SATA drives in RAID 5 opstelling. Ik krijg hier max zo'n 92MB/s uit, wat niet echt goed is voor RAID5, maar wat toch zeker wel voldoende moet zijn voor goede performance.

Het probleem wat ik heb is dat zodra er een boel requests naar de server gaan, dat het tot wel 30 seconde duurt voordat een bestand begint te laden. In het begin gaat het nog wel goed, maar binnen 10 minuten zit de boel goed vast. Ik kan wel gewoon goed inloggen via Shell, en daar dingen doen.

Ik heb een 100MBit lijn tot me beschikking, en de netwerk load komt nooit boven de 35Mbit/s. Er is dus nog genoeg bandbreedte beschikbaar.

De server load komt verder nooit boven de 0.3, en CPU is altijd 95% idle.

Hoe kan het dan het dan toch zijn dat er zo lang gewacht moet worden voordat bestanden beginnen te laden? Kan het iets met APACHE te maken hebben, doordat het allemaal grote files zijn die ingelezen worden?

Alle tips zijn welkom.

[Verwijderd]

Ik ervaar trouwens het zelfde probleem op m'n FreeBSD bak, met zelfde HW specs.

[Arjan A]

Ik mis een heleboel relevante informatie:

Je hebt het over een aantal fileservers en een webserver.
Welke bak doet wat, en hoeveel heb je ervan?
Hoe krijgt Apache de bestanden? SMB/NFS/???

Wat heb je allemaal geprobeerd om de snelheid hoger te krijgen?

[Verwijderd]

Arjan A schreef op maandag 16 mei 2005 @ 01:13:
Ik mis een heleboel relevante informatie:

Je hebt het over een aantal fileservers en een webserver.
Welke bak doet wat, en hoeveel heb je ervan?
Hoe krijgt Apache de bestanden? SMB/NFS/???

Wat heb je allemaal geprobeerd om de snelheid hoger te krijgen?

Sorry voor de verwarring. Het gaat hier om 3 fileservers, althans ze dienen als filesservers.

Ze draaien gewoon op APACHE, port 80.

2x redhat en 1x freebsd.

Ik heb DMA enzo op de HD's aangezet.

Verder heb ik nog niets aan APACHE oid gedaan, omdat ik niet weet wat ik moet veranderen voor performance winst voor deze setup.

Het is een standaard install, ik weet niet precies wat SMB/NFS is.

Omdat hier veel grote files IPV normale .html en .php bestanden worden opgevraagd, moet er misschien ergens iets verandert worden. Weet alleen niet wat, en daarom mijn topic.

[Bergen]

Apache is een webserver, geen fileserver. Hoe haal je die bestanden nu op, echt via Apache? Dus als je een bestand wilt hebben dan haal je dat op met je webbrowser? Waarom doe je dat niet via Samba?

[Verwijderd]

Bergen schreef op maandag 16 mei 2005 @ 03:24:
Apache is een webserver, geen fileserver. Hoe haal je die bestanden nu op, echt via Apache? Dus als je een bestand wilt hebben dan haal je dat op met je webbrowser? Waarom doe je dat niet via Samba?

Ik heb persoonlijk nog nooit met Samba of een andere fileserver los van Apache gewerkt?

Zou ik dus in een situatie zoals deze met iets anders dan Apache moeten werken? En waarom precies.

[Bergen]

Nou, je kunt natuurlijk wel bestanden ophalen met Apache, maar dan heet het "downloaden". In principe download je een bestand van je webserver, je haalt niet een bestand van een fileserver. Als je Samba installeert kun je een directory op de server in je verkenner als harde schijf zien, met een eigen driveletter en alles. Dat werkt veel prettiger.

[Verwijderd]

Maar die features hoef ik allemaal niet. Het gaat hier om .wmv files die in een media player geladen worden. Het bufferen gaat dus langzaam.

Kan het niet aan de config van apache liggen? Omdat apache standaard met alleen maar kleine files werkt IPV grote?

[Mad Marty]

Lees eens wat er gezegd wordt: Apache is een WEBserver, geen FILEserver. Je gebruikt het verkeerde programma voor je taak; gebruik Samba voor wat jij wilt.

[Bergen]

Verwijderd schreef op maandag 16 mei 2005 @ 08:01:
Kan het niet aan de config van apache liggen? Omdat apache standaard met alleen maar kleine files werkt IPV grote?

Nee, het maakt Apache geen zak uit hoe groot een bestand is.

Voor je probleem met het aantal tegelijktijdige verzoeken zou je natuurlijk de serverpool wat groter kunnen maken, maar dat had je zelf vast ook al gezien. (Tenminste, ik neem aan dat je zelf al even httpd.conf had doorgelezen, toch?)

[edit]
ja, ik ga er idd ook even vanuit dat je clients Windows draaien...

[ Voor 14% gewijzigd door Bergen op 16-05-2005 11:20 ]

[Tatsu]

Als de clienten Windows als OS hebben, kun je het best Samba gebruiken. Als je toch apache hebt draaien, kun je met SWAT Samba heel makkelijk configureren.

[Wolfboy]

Wie zegt dat de clients in hetzelfde netwerk zitten?
Het zou ook heel goed kunnen dat de servers in een datacenter zitten en dat hij wegens beveiligingsredenen geen samba kan gebruiken, sowieso is het gebruiken van samba niet de oplossing van zijn probleem.

@TS: probeer ook eens te testen hoe snel het gaat als je de bestanden via ftp oid. overzet, test de beschikbare bandbreedte met netio.

En nog een ander (m.i. belangrijk punt) is het hardware of software RAID?

[SPee]

Probeer je dat in een lokaal netwerkje of via internet.

Als het gewoon lokaal is, is samba de beste oplossing. Via internet, is dat geen oplossing en zul je inderdaad het via een webbrowser moeten doen (oid).

Als je met WMP een .wmv of .wma bestand wil openen, wil hij eerst deze compleet gebufferd hebben. D.w.z. dat hij die bestanden lokaal wil hebben. Via een lokaal netwerk via samba is dat minder nodig. Via internet wil hij eerst dat bestand lokaal in de cache hebben. Dus kopieert hij eerst het volledige bestand (met al die http requests overhead) en dan gaat hij dat bestand pas openen. Daarom duur het zo lang.
Als Samba geen oplossing is, zou je kunnen proberen of streaming files niet beter aansluit op jouw wensen.

Wat ook kan zijn, is dat je in Apache een limiet op de snelheid (per verbinding) hebt gezet, waardoor ze nooit de maximale snelheid behalen.

[ Voor 9% gewijzigd door SPee op 16-05-2005 11:28 ]

[M-ThijZ]

Heeft de TS juist geen streaming video en gaat hem dat te langzaam? Volgens mij wil hij juist uitzoeken waarom het zo lang duurt voordat een video begint te streamen.

[Paul]

Tatsu schreef op maandag 16 mei 2005 @ 11:17:
Als de clienten Windows als OS hebben, kun je het best Samba gebruiken. Als je toch apache hebt draaien, kun je met SWAT Samba heel makkelijk configureren.

offtopic:
Voor swat heb je geen apache nodig swat wordt zelf door inetd aangeroepen en is zelf een webserver die default luistert op poort 901 (maar wat je dus in de config van inetd aan kunt passen)

[Verwijderd]

Sorry als ik onduidelijk was, maar het ging dus niet om servers bij mij thuis, maar servers die in een data center in the US staan.

Ik heb zojuist wat instellingen in APACHE verandert, en ik heb nu totaal geen last meer van de langzame laadtijden. Wat dus heel mooi is. Ik heb 'Keep Alive' op OFF gezet, dit stond op ON. En ik heb 'MaxKeepAliveRequests' van 1000 naar 100 verlaagd.

Verder heb ik in <IfModule prefork.c> MaxClients van 256 naar 512 verhoogd, en in <IfModule worker.c> MaxClients van 150 naar 300 verhoogd.

Voor de rest is het nog gewoon de standaard config die bij me server zat.

Timeout 300
KeepAlive Off
MaxKeepAliveRequests 100
KeepAliveTimeout 15

<IfModule prefork.c>
StartServers 10
MinSpareServers 5
MaxSpareServers 10
MaxClients 512
MaxRequestsPerChild 0
</IfModule>

<IfModule worker.c>
StartServers 2
MaxClients 300
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 25
MaxRequestsPerChild 0
</IfModule>

<IfModule perchild.c>
NumServers 5
StartThreads 5
MinSpareThreads 5
MaxSpareThreads 10
MaxThreadsPerChild 20
MaxRequestsPerChild 0
</IfModule>

MinSpareServers 5
MaxSpareServers 10

StartServers 5

MaxRequestsPerChild 100

Ik weet niet precies welke setting nou echt de performance winst heeft behaald. Zien jullie nog andere dingen waarmee de performance winst vergroot kan worden?

Ik draai trouwens hardware RAID 5, niet software.

Wat me ook opvalt is dat het geheugen gebruik van de server rond de 72% blijft hangen. Dit is meestal toch 95% tot 98% op linux/freebsd servers?

[ Voor 8% gewijzigd door Verwijderd op 16-05-2005 16:12 ]

[Bergen]

Oww... Als het over een fileserver hebt denkt volgens mij iedereen dat dat ding bij je thuis files staat te serveren.

Anyway, ik denk dat vooral het maximale aantal clients heeft geholpen, nu hoeft hij niet te wachten tot er weer een client beschikbaar komt. KeepAlive kun je beter weer aanzetten, anders moet er voor elk klein verzoekje een complete nieuwe connectie gemaakt worden.

[Verwijderd]

Ok, thanks

Kan ik het nummer van max clients nog gewoon verder verhogen dan? Wordt de performance daar dan weer beter van?

[Bergen]

Dan moet je kijken hoeveel hits je pagina krijgt... en dan ongeveer bedenken hoeveel bestanden er tegelijkertijd verstuurt zouden kunnen worden. Dat kunnen wij natuurlijk niet voor je beoordelen. (maarja, je zou ook niet zeggen dat er meer dan 200 connecties tegelijkertijd open zouden staan, dus wat dat betreft kan ik 't performanceverschil nog niet helemaal verklaren...)

[ Voor 32% gewijzigd door Bergen op 16-05-2005 17:30 ]

[dawuss]

Kun je eens even kijken met behulp van hdparm of DMA aan staat op je server?

Iets zegt me dat het daar wel eens iets mee te maken kan hebben

[Verwijderd]

Bergen schreef op maandag 16 mei 2005 @ 17:29:
Dan moet je kijken hoeveel hits je pagina krijgt... en dan ongeveer bedenken hoeveel bestanden er tegelijkertijd verstuurt zouden kunnen worden. Dat kunnen wij natuurlijk niet voor je beoordelen. (maarja, je zou ook niet zeggen dat er meer dan 200 connecties tegelijkertijd open zouden staan, dus wat dat betreft kan ik 't performanceverschil nog niet helemaal verklaren...)

Ik denk juist wel dat die 200 makkelijk openstaan. Kijk .wmv files van bv 5MB, beginnen al met afspelen na dat ze iets van 300KB ingeladen hebben. Als mensen dus een langzame verbinding hebben is een process, lijkt mij, erg lang actief.

Het gaat hier om de fileservers van www.dumpalink.com. Ik trek daar ruim 3 (MEDIA PAGE, pageview per seconde). Dat zijn dus 3 requests naar de fileserver voor een media bestand per seconde.

dawuss schreef op maandag 16 mei 2005 @ 17:31:
Kun je eens even kijken met behulp van hdparm of DMA aan staat op je server?

Iets zegt me dat het daar wel eens iets mee te maken kan hebben

Had ik al gezegt Verwijderd in "Linux langzame mediafiles-server"

Staat al aan DMA.

[GlowMouse]

Hoewel je hardwarespecs (oa 1GB RAM) erg goed zijn, blijft Apache een beetje verspilling van resources voor jouw toepassing. Voor static files en weinig overbodige instellingen kun je beter een kleine webserver gebruiken, bijvoorbeeld thttpd.

[Bergen]

Als 't zo'n drukke server is kun je het aantal nog wel wat opschroeven ja... Beter teveel dan te weinig.

[Verwijderd]

Ok, zal ik dat vannacht even proberen als het rustig op die bak is. Kan nu niet rebooten.

Gaat het om <IfModule prefork.c> of <IfModule worker.c> trouwens?

[Seth4Chaos]

Verwijderd schreef op maandag 16 mei 2005 @ 17:51:
Ok, zal ik dat vannacht even proberen als het rustig op die bak is. Kan nu niet rebooten.

Gaat het om <IfModule prefork.c> of <IfModule worker.c> trouwens?

Ik hoop toch niet dat je het rebooten van de server bedoelt he? Als je een paar instellingen wijzigt kan je gewoon een herstart van apache zelf doen (dan zullen er voor korte tijd geen request gedaan kunnen worden) of je kan apache een SIGHUP sturen en dan leest die zelf de config opnieuw in en heb je dus helemaal geen downtime.

Maar, zoals Glowmouse al zei, als je echt apache alleen gebruikt om simpele files te serveren kan je beter kijken naar een http-server met een stuk minder overhead, hou je meer resource over dus kan je meer requests aan

[Sendy]

Ik zou pas switchen van server software wanneer de machine werkelijk te traag wordt. Zolang je geheugen vrij hebt (en je load laag blijft) dan zou ik lekker bij Apache blijven.

Ik las laatst trouwens iets over kernel.org, ook een drukbezette website (waar Linux-kernels van geserveerd worden). Ze spraken daar nog over wat filesystem tweaks. Hier.

[Verwijderd]

Lol, nee heb hier ff geen shell toegang

Ik hou het toch bij apache, ik upload me files namelijk via een .php scriptje, en die heb ik echt nodig. Kan ook via een extern .php script met FTP verbinding, maar goed het gaat prima zo. Server doet lekker z'n werk op het moment. Verder komt er morgen nog een servertje bij met de zelfde config om de boel te versterken.

[Bergen]

/usr/local/apache/bin/apachectl restart
(oid)

downtime van euh... 1 seconde ofzo

[Verwijderd]

Nu het weer wat drukker is duurt het weer enorm lang voordat er ook maar iets gebeurt. De serverload is nog steeds 0.1, dus enorm laag.

Ik heb MAX client verhoogd naar 700, maar goed er zijn toch maar 350 processen actief als ik 'TOP' draai.

Zit echt met me haren in me hoofd waarom dit nou het geval is.

[4VAlien]

met 350 processen en 100mbit blijft er ongeveer 36KB per proces over geen wonder dat het dan langzaam gaat.

[Wolfboy]

4VAlien schreef op maandag 16 mei 2005 @ 21:38:
met 350 processen en 100mbit blijft er ongeveer 36KB per proces over geen wonder dat het dan langzaam gaat.

350 processen wil niet zeggen dat er 350 clients zijn en al zeker niet dat er 350 clients aan het downloaden zijn.
Dat verhaal gaat hier dus niet op.

[Verwijderd]

Idd, iptraf geeft nu 25Mbit/s aan. Er is genoeg bandbreedte beschikbaar.

Zijn er misschien testjes die ik kan doen, waarmee het probleem naar boven kan komen.

[Weppel]

Zet server-status eens aan (en zet ExtendedStatus op On) en kijk daar eens heen, misschien zit je toch vaak aan je max client limit en zul je dit moeten verhogen naar bijv. 1000 of 1500 clients.

[Verwijderd]

Hij staat nu op 1500, en nu eht weer erg druk is, zijn de laad tijden weer vrij lang. Als hij eenmaal bezig is met bufferen, gaat het prima. Goede snelheid enzo, alleen het duuurt 20 sec voordat hij begint met bufferen.

Kan er niet bij met me verstand

[Sendy]

Je moet dan toch beter gaan debuggen. Wat gebeurd er bijvoorbeeld met kleine bestanden? Krijg je die wel snel? Hoeveel Apache processen draaien er als het druk is? Wat bedoel je met actieve processen? Running, sleeping of beide?

[Bergen]

Verwijderd schreef op dinsdag 17 mei 2005 @ 17:56:
Hij staat nu op 1500, en nu eht weer erg druk is, zijn de laad tijden weer vrij lang. Als hij eenmaal bezig is met bufferen, gaat het prima. Goede snelheid enzo, alleen het duuurt 20 sec voordat hij begint met bufferen.

Kan er niet bij met me verstand

1500 is wel veel, maar als het echt druk is, verwacht je dat er dan wel 1500 mensen tegelijk filmpjes aan 't kijken zijn?

Sendy schreef op dinsdag 17 mei 2005 @ 19:15:
Wat bedoel je met actieve processen? Running, sleeping of beide?

[mierenneukmodus]
De R staat voor runnable, niet running
[/mierenneukmodus]

[Weppel]

Heb je apache wel gecompiled met een hogere userlimit? Standaard (zonder aanpassingen) compilen levert een harde clientlimit van 256 op...

[Sendy]

Bergen schreef op dinsdag 17 mei 2005 @ 23:02:
[mierenneukmodus]
De R staat voor runnable, niet running
[/mierenneukmodus]

En het verschil is dus alleen technisch? Want een processor kan maar een (1) proces tegelijk draaien? Virtueel draait zo'n proces natuurlijk wel. Bedoel je dat?

Ik zie het nu ook staan in de man van ps:

code:

R    Running or runnable (on run queue)

edit:
Oke, je bedoeld hetzelfde als wat ik bedoel

[ Voor 8% gewijzigd door Sendy op 18-05-2005 22:06 ]

[Bergen]

Nou, in mijn "grote Linux-boek" legt het zo uit:

A runnable process is ready to execute whenever CPU time is available. It has acquired all the resources it needs and is just waiting for CPU time to process its data. As soon as the process makes a system call that cannot be immediately completed (such as a request to read part of a file), Linux will put it to sleep.