|
Hi,
OK, I'll try to create patch, may be tomorrow.
Ok.
Good idea for Joe, he can add it to configure-lvs but
of course any other users can's see it. What to say, people
running such big system should tune the kernel :) If there are
no recommendations for kernel settings may be we can write
such document? :)
Yes, I've already started with the /proc/slabinfo as you might have seen :)
As for gc_thresh*:
- if entries are more than gc_thresh2 => run GC on each 5sec
What does it do exactly? Could you point me to the code?
- gc_thresh3: max number of entries
Yes, I'm glad I picked the right one.
Yup, forget about that one. But normally this is high enough, not? Also
Yes, it is calculated based on the installed RAM.
How? The same thing as with netfilter buckets?
No influence from other parameters if you are hit from
high load (many hosts contacting you). Sometimes the garbage
collection algorithm (GC) can not reduce the total cache entries
below the max_size and we see the "dst cache overflow"
message when the load is high.
This does make sense. Why are those values so low as a standard? Most
boxes nowadays have GBytes of memory :)
Ops, there is no such message in the logs, so may
be only the neighbour cache should be tuned.
You mean the expiration cache or the max entries value?
Yes, when the memory is full bad things happen. I remember
the 2.2 system behave very badly when some page order is exhausted
and the network receives ENOBUFS/ENOMEM while at the same time
the buffer cache shows big number of pages, vary bad. I didn't
tried the 2.4 with the same load, I hope the 2.4+ kernels
handle this properly.
I never had this problem, but I never had such a setup either.
Best regards,
Roberto Nibali, ratz
--
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc
| 