#musicbrainz

inhouseuk: ;)

now its tapering off again

works here ok.

I also restarted it in the meantime.

you previously said about no resolving ip in apache logs

what about other directives, i mean Allow using hostnames?

yeah?

do You use sth like it?

sth?

something

something, i mean 'Allow from myhostname.com'

and not the 'Allow frmo 1.2.3.4'

I doubt iot

no names in Allows at all.

only ips

was anything modified recently in httpd.conf or apache conf?

from what I'm seeing, it's taking time to respond to the initial SYN

radekdev: not really

inhouseuk: rather not SYN but initial payload. synack was sent promptly.

inhouseuk: you can check this in zim.tcpdump.out file line 11

yeah, I can see it now

yup, we're plain using too many apache procs

and we can't up it since we do not have more memory.

off by a week you wankers!

Hello all

hi

hi

donredman: Thanks :)

Now I won't have to bug ppl to delete my attachments for me. ;-)

ruaok: too many apache procs for the number of db connections allowed?

we're simply at maxclients

hi djce !

the digg wankers. :-)

hey

lol

djce: kevin is logged into zim right now.

and we just upped apache2 max clients to 100

well, maxclients might as well be 1 right now, given that we have zip in terms of bandwidth.

kevin used to tune friendster

he's qualified. :)

djce: its not a bandwidth issue

ftp works GREAT

ruaok: really? scp sucked ass.

ya. worked fine.

things are certainly improving now.

almost usable again

the bandwidth graphs are climbing

yup.

kevin is a genius.

what was maxclients before?

I can normally get to fill my line

50

I'm getting 8Kb/s

Personally, I don't believe this is anything to do with zim's software configuration.

djce: what is your theory then?

lack of outbound bandwidth would cause the number of apache procs to climb

right, because they're all waiting to send their data.

yup

which is exactly what I was seeing earlier.

It's a bandwidth issue, plain and simple IMO.

maybe a NIC, maybe a cable, maybe a router, who knows.

but it's network throughput.

djce: not conviced about bandwith

why so?

djce: how can You explain that dumps shows 30s delay at eth0

we're not being throttled and HE is not experiecing any problems

with sending initial payload from apache - syn ,synack, ack were ok, than 30s

thats a plain sign of apache 'waiting for sth'

ruaok: as to the maxclients - what is strange for me, that in vmstat output you showed there was no information about processes waiting...

maybe the response isn't ready to send, because of bandwidth problems.

ruaok: thats why i didnt even ask for it ;)

djce: nope

djce: that was dump of server eth0

and there was plain silence.

Your logic doesn't necessarily follow.

so if we're talking about throttling it would have to be a throttling installed on the server itself.

djce: please explain me - maybe i'm wrong.

What HTTP request were you making during this test?

mb seems quite snappy now.

djce: could you look at files provided by ruaok ? it would be much simpler. look at difference between line 10 and 11 in zim file.

djce: we upped the back end max to 30

yup, things are almost acceptable now

that still doesn't explain the slow ftp transfer speeds

How do you plan to stop zim running out of memory?

kevin did some math and hopes this will keep us out of it

When MaxClients was higher before, zim kept running out of memory and killing stuff (e.g. sshd)

ick.

And in any case, mainly I'm curious to know what (presumably) changed at about 5.45am your time to cause things to go tits up.

djce: you and me both.

the only explanation I have is that traffic exceeded out capacity and things got 'stuck'

Hmmm.

(That's <hmmm type="sceptical">)

i'm with you and that.

none of this is making sense.

any response from the hosting center?

yes, no throttling and all systems normal

I'm still getting totally sucky ssh performance

ssh via catbus works great

exactly.

ruaok: if that was not resolving issue, please revert back change to /etc/resolv.conf

tahnks for the reminder

well, I prefer learning about apache tuninig in a more sane fashion, but at least I learned a few things today. I think.

Yeah, you can't run a busy web server on sucky bandwidth :-/

well, I'll get the new machines installed tomorrow.

hopefully we can have everything configured by the weekend.

I'd love to cut over on sat.

then go fetch the other servers on sunday.

will that help with bandwidth?

we'll have 3mbit of our own bandwidth then.

and no one to share it with.

oic

and no one will share our bandwidth bill either. :-(

397331 bytes received in 01:10 (5.46 KB/s)

that's dialup speed :(

vrooom vrooomm clunk.

can i hear anyone say "MP3 SERVER"

MP3 Server.

why?

3mbit of own bandwidth, hehe

ah. :-) all legit mp3s, of course.

course

hey ho. enough fun for one day.

night all!

nite

ruaok: don't forget to ask djce to reduce the TTL on the dns records ready for the move to the new colo

inhouseuk: he already did that. :-)

10000 seconds is still high for a server move