Greetings,
Stefan Lambrev wrote:
Greetings,
Kris Kennaway wrote:
Stefan Lambrev wrote:
Greetings,
Kris Kennaway wrote:
Stefan Lambrev wrote:
I'll use again hwpmc and LOCK_PROFILING to see what's going on.
And will try the same benchmark on quad core processor as now
numbers of cores/cpus matter :)
Here are promised results -
http://89.186.204.158/lock_profiling-8.txt
Finally I got pmcstat working - http://89.186.204.158/hwpmc-p4.txt
The stats are gathered during 600kpp incoming.
I think that syncache or what calls MD5Transform is not SMP able,
and that's why outgoing 250kpps is the limit that I can't beat.
It looks like the syncache is using most of the CPU time. However
you are not hitting problems caused by lack of concurrency there. It
does do a *lot* of work with the syncache mutex held (including
generation of the cookie, which involves MD5) so it might be an issue
in the future, but there are other bottlenecks in the way before that
is your main issue. Things may be different with more CPUs.
Did you compare to what happens to performance when the syncache is
disabled?
Kris
When I disable syncookies the server respond to more packets - from
250kpps enabled to 320kpps when disabled.
Can I disable syncache and how?
Err you answer this already :)
So here are numbers in different syncache/coockies options:
net.inet.tcp.syncookies: 1 & net.inet.tcp.syncookies_only: 0
input (em0) output
packets errs bytes packets errs bytes colls
519748 0 31184880 252606 0 14651090 0
522321 0 31339260 251459 0 14584490 0
532242 0 31934520 242768 0 14080486 0
533484 0 32009040 249006 0 14442522 0
net.inet.tcp.syncookies: 0 & net.inet.tcp.syncookies_only: 0
input (em0) output
packets errs bytes packets errs bytes colls
512100 0 30726000 316873 0 18378866 0
517952 0 31077120 315868 0 18320270 0
531862 0 31911720 318416 0 18468244 0
526125 0 31567440 315283 0 18286340 0
net.inet.tcp.syncookies: 0 & net.inet.tcp.syncookies_only: 1
input (em0) output
packets errs bytes packets errs bytes colls
517257 0 31035420 315739 0 18310890 0
518328 0 31099680 316888 0 18381534 0
517168 0 31030080 316693 0 18368426 0
528273 0 31696320 315722 0 18311670 0
533153 0 31989240 314693 0 18252136 0
net.inet.tcp.syncookies: 1 & net.inet.tcp.syncookies_only: 1
input (em0) output
packets errs bytes packets errs bytes colls
539069 0 32344140 282434 0 16381272 0
538075 0 32284440 281569 0 16330886 0
538329 0 32299800 281908 0 16350880 0
534111 0 32046660 280906 0 16292258 0
536204 0 32172240 281169 0 16307860 0
Increasing net.inet.tcp.syncache.hashsize to 2048 (512 default)
input (em0) output
packets errs bytes packets errs bytes colls
532945 0 31976700 186833 0 10835096 0
533507 0 32010420 187053 0 10850292 0
530204 0 31812240 187672 0 10883758 0
531482 0 31888920 187585 0 10879930 0
534651 0 32079060 186977 0 10845884 0
This prove that syncache have negative impact on performance ?
I'll try to increase syncache limits and will test again.
Btw is this expected - net.inet.tcp.syncache.count: -387.
I think this number should be always > 0.
--
Best Wishes,
Stefan Lambrev
ICQ# 24134177
_______________________________________________
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
