more on bogged down server
Harold Hallikainen
harold at hallikainen.com
Mon Apr 10 22:53:12 UTC 2006
>
>> You have to reduce your load somehow. Ideally, you should create an
anonymous FTP download directory and move all of the downloadable files
to it. The download directory also is used as the home directory for
the anonymous FTP user (user "ftp"). I actually use a completely
separate filesystem entirely for that. The filesystem is mounted so
that only root has write access.
>> Modify your vsftpd.conf file to permit anonymous downloads only and
start up vsftpd. Make sure you also set the "force chroot for
anonymous users" option. Then change your links on your web pages to
use "ftp://"-style links pointed at the anonymous download directory
paths for the downloadable files.
>> FTP is the protocol to use for large file downloads. HTTP just isn't
efficient for that, as you've now found out (the hard way, I might
add).
>
> as the man said, dont use http for this,
>
> if you must then i suggest that you have a separate partition for your
large files and make fstab read as such (example)
>
> /dev/web / ext3 defaults,directio 1 1
>
> add the directio comment and the file will not go to ram, nor to swap.
this will speed up things, but you should hand the downloads over to a
different method (not http).
>
THANKS! I'll see what I can do about moving stuff to ftp. Most of the
large files are on phpwiki. I suppose I could slowly go through the pages
and change the download files (mostly scanned pdfs) from http:// to ftp://
. Any problem with having the ftp download directory being the same as the
http root directory? That way I would not have to move anything, just
change the protocol prefix on the links.
Here's another top. It looks like 98.6% of ram is being used, along with
100% of the processor. Not much swap space is being used. It kinda seems
like Apache just tries to use as much RAM and CPU as is available. I guess
this would be ok if my DSL could send the data out faster (I'm sure that's
why these threads live so long). But, it doesn't seem like it should 7% or
more of the CPU to a byte from the drive to the ethernet. Maybe ftp's just
more efficient at this?
Cpu(s): 99.7% us, 0.3% sy, 0.0% ni, 0.0% id, 0.0% wa, 0.0% hi, 0.0% si
Mem: 1027640k total, 1013636k used, 14004k free, 7032k buffers
Swap: 2031608k total, 368k used, 2031240k free, 284780k cached
Cpu(s): 99.7% us, 0.3% sy, 0.0% ni, 0.0% id, 0.0% wa, 0.0% hi, 0.0% si
Mem: 1027640k total, 1013636k used, 14004k free, 7032k buffers
Swap: 2031608k total, 368k used, 2031240k free, 284780k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2414 apache 25 0 60892 35m 5644 R 6.6 3.6 14:29.37 httpd
3231 apache 25 0 51028 25m 5480 R 6.6 2.6 8:13.30 httpd
3683 apache 25 0 60700 35m 5404 R 6.6 3.5 7:50.11 httpd
4082 apache 25 0 60672 34m 4580 R 6.6 3.4 13:18.66 httpd
4577 apache 25 0 50072 24m 5320 R 6.6 2.5 1:03.57 httpd
4578 apache 25 0 50488 25m 5392 R 6.6 2.5 4:14.42 httpd
4592 apache 25 0 60196 34m 5168 R 6.6 3.4 5:02.36 httpd
2411 apache 25 0 60664 34m 4908 R 5.3 3.5 22:12.54 httpd
4548 apache 25 0 50352 23m 3804 R 4.3 2.4 4:32.46 httpd
2410 apache 25 0 60916 35m 5388 R 3.3 3.5 24:34.60 httpd
2412 apache 22 0 51012 25m 5508 R 3.3 2.6 8:35.88 httpd
2415 apache 25 0 60752 35m 5532 R 3.3 3.5 20:26.07 httpd
2417 apache 23 0 60528 35m 5556 R 3.3 3.5 33:19.76 httpd
3239 apache 25 0 61024 35m 5544 R 3.3 3.6 12:13.21 httpd
3365 apache 25 0 50832 25m 5596 R 3.3 2.6 6:40.87 httpd
3379 apache 25 0 60068 34m 5480 R 3.3 3.5 4:07.17 httpd
3923 apache 25 0 60640 34m 4660 R 3.3 3.4 9:40.94 httpd
4482 apache 25 0 59580 34m 5428 R 3.3 3.4 0:29.00 httpd
4848 apache 24 0 49892 24m 4868 R 3.3 2.4 0:40.70 httpd
4989 apache 25 0 50028 22m 2964 R 3.3 2.2 2:05.30 httpd
5380 apache 25 0 49644 22m 2952 R 3.3 2.2 0:07.94 httpd
4826 apache 25 0 59936 33m 4712 R 3.0 3.4 2:45.52 httpd
4582 apache 15 0 45420 20m 5532 S 0.3 2.0 0:03.01 httpd
5431 harold 16 0 2020 1036 796 R 0.3 0.1 0:00.05 top
Again, THANKS to all for the help!
Harold
--
FCC Rules Updated Daily at http://www.hallikainen.com
More information about the Redhat-install-list
mailing list