Re: Using old CPU for 100s of clients

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

	Why type of NICS are you using ?

With random slowness it could be anything ... for example:

I used to work as Escalations person for a security appliance company.
We had this customer call in on a regular bases because his network
performance was crap.

From the start our suggestion was to replace his network cards ... but
he would not listen. He was using old desktop based cards, as most
manufactures create desktop and server class nics.

Desktop based nics have mid sized receive buffers and small out going
buffers. This is because as a rule desktop PC's receive more data then
they send.

Using these nic's in a server can have serious performance impacts with
regards to network traffic. So it would not matter how many network
cards you tried ... if you are not using server class nices ... then
your network throughput would be crap.

What type of PC is a DEC Prioris ?

The performance problem could be related to the poor design and lack of
performance in the PC.

For example I have a PC with PIII 1Ghz with 384 MB of RAM running
slackware linux. I just put in a Seagate Baracuda 200GB 7200 RPM drive
so this box should be screaming. But I find it slow ... from the testing
I have done ... all I can think of is because it is a Compac NE... which
is this little PC only big enough for 1CD-rom, 1 HDD and 1 FD0 ... that
is all ... nothing else will fit in there.

If I am using the HDD and nothing else not to bad if I am copying data
from the CD-rom to the HDD the machine crawls to the point where you can
not do anything.

At work ... I have standard PC ... with a fake Pentium, older drive but
I can burn CD's, still use my fluxbox plus listen to mp'3  with XMMS --
I also use 3D desktop to switch desktops.

So as you can see ... there are so many factors. So I don't think it is
the CPU that is causing the slow down ... just everything else in the box.

Michael.	


Shawn Wright wrote:
On 3 Dec 2004 at 12:22, Daniel Chemko wrote:


The Speed problems may not be isolated to your CPU. You'll want to make
sure your conntrack table isn't getting full, and that conntracks are
safely getting expired from your system. Are you using a custom kernel,
or a stock distro one?


Thanks for the reply. I didn't give many details because I've already beat this to death on the Shorewall list before coming here (I know, I should have started here). It is a custom kernel, as all of the recent stock kernels will not boot on this machine - APIC must be disabled (it's an old DEC Prioris). I have tried 2.4.22, two different Mandrake releases, along with a plain 2.4.28 from kernel.org. It is possible that I've messed up somehow, so I plan on taking a stock 2.4.22-37mdk kernel that currently runs well on a P3/667, and compile it, making no change except for CPU support and APIC. This might help isolate the problem.


Just for fun, could you forward me the following:

# cat /proc/loadavg

Load average *never* goes above 0.3, currently all zeros... I don't believe the system CPU% factors into the loadavg though?


# free

total used free shared buffers cached Mem: 223208 219472 3736 0 0 127028 -/+ buffers/cache: 92444 130764 Swap: 409616 0 409616


# iostat 20 2 (sysstat package is nice for accounting)

don't have this installed, although I plan to...



# top (grab the CPU lines, over time is best)

top will show up to ~13% system CPU% during a load test when I pass 1000kB/s + across the 10Mb link. Otherwise, it is rarely over 5% system.



# cat /proc/slabinfo

I've looked at this also - our peak conntrack count is around 4000, max is set to 16K. I've also tried it at 64K, and set the hashsize upon load of ip_conntrack module to 64K, just for fun, made no difference.



# cat /proc/net/ip_conntrack | wc -l

Usually around 1500, but I have seen 4000 peak.



# hdparm /dev/<your disk(s)>

This is from the "bad" machine. All machines use a 3940 PCI SCSI with aic7xxx driver, and one or more Seagate Cheetah 10K 9Gb drives.


/dev/sda:
 readonly     =  0 (off)
 geometry     = 1106/255/63, sectors = 17783240, start = 0


# cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max

Tried 16k and 64k...


# netstat -i

This is from current live firewall (the good one). The bad one has been rebooted since the last time I tried it live, so no data.
Kernel Interface table
Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0 1500 058662850 1 0 074520718 3 0 0 BMRU
eth1 1500 074674696 0 0 057280898 0 0 0 BMRU
lo 16436 0 89156 0 0 0 89156 0 0 0 LRU



# mii-tool

I've used this exhaustively to check the NICs are setup right. The outside NIC goes to a Cat1900 forced 10FD, and they are notoriously bad at playing nice with NICs. No errors though as you can see above on eth1.
The inside link is 100Mb FD to a Cat 3500, and again no errors. Current NICs are one Intel E100B (eepro100 driver), and a Dlink DFE500TX (tulip driver). I have tried all combinations of e100/eepro100/tulip with half a dozen different NICs, no change in symptoms.


I should mention that we can reproduce the problem within a few minutes of hitting random web sites, waiting for one to "hang". We've eliminated our DNS and proxy as sources of the problem - it occurs when bypassing proxy and NATing through firewall. Have tried 3 different DNS servers, squid reports avg DNS times of < 100ms. We're talking up to 20sec delays before getting data from a website, even timeouts. A second visit to same site, different pages, is quick. To duplicate we need to hit random sites, but can do so within a few minutes, even when network load is low.


wow.. there are a lot of areas to look into.. Anyways, hope to find
something.


So do I...


Good ol' BC boy!


Nice to hear from someone nearby! :-)

Thanks!
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Shawn Wright, I.T. Manager
Shawnigan Lake School
http://www.sls.bc.ca
swright@xxxxxxxxx








-- Michael Gale Lan Administrator Utilitran Corp.

Linux: because a PC is a terrible thing to waste !!!



[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux