Высокая нагрузка на процессор - с чего бы?

[GribUser]

Интересное наблюдение... Раньше у меня акселератором был squid и он в
плане загрузки процессоров вообще не светился. Страшно было смотреть на
MySQL в top, но о squid я вообще вспоминал только потому, что он память
терял, а у меня свап был не сильно большой.

Теперь же стоит nginx и он (обычно один из worker processes, остальные
далеко внизу, но вот сейчас сразу три переплюнуть MySQL умудрились -
ужасть!) устойчиво занимает первое место в top. Я могу понять, что он
обогнал httpd (хотя squid httpd обгонял у меня нечасто, у меня gzip в
mod_perl делается, и сейчас, кстати, еще), но каким макаром он
умудряется обогнать mysql, ворочающий довольно приличных размеров
статистику и раньше занимавший ~90%+ проессорного времени, оставляя
сквиду 3-5%?

Куда надо смотреть, чтобы понять, что происходит? Может, дело в том, что
squid самостоятельно кэшировал в памяти статику, единожды утянув с
бэкэнда, и раздавал клиентам из своего кэша, а nginx ее тягает с диска и
перекладывает оптимизацию на ОС со столь плачевным результатом? Похоже
на то, что kernel и user поровну считают или kernel даже больше во время
мега-работы nginx, хотя во время работы MySQL в kernel вообще ничего не
считается, просто 0%, походу, все под юзером. Есть идея, что ему очень
срывает башню от 404-й ошибки, когда он сам не может найти страницу, но
со 100% вероятностью не скажу, еще надо наблюдать. Иногда, редко, его
клинит так, что он под 100% вообще процессор занимает при средней
загрузке в районе ~10%, но я что-то не уловил закономерности, хотя раз
его точно заклинило, когда была серия из ~20-и запросов несуществующего
файла (gif) в nginx.

Я, вообще, планирую плотно понаблюдать за nginx недельку, а потом опять
попробовать squid. Железо и ось я тоже поменял, так что всякие могут
быть объяснения. Но хочется и понять же, откуда могут ноги расти у такой
странности, в теорию въехать. Вот конфиг. Работает на Solaris 10, два
камня+HT=4 псевдо-камня, кэш 2MB. 100% трафика с прокси идет уже пожатым
GZIP, там есть пара статических сайтов генерящих что-то типа 3% общего
трафика, для них я общий gzip включил.

Собрано --with-pcre=../pcre-5.0/ --with-cpu-opt=pentium4
===============
Configuration summary
  + threads are not used
  + using PCRE library: ../pcre-5.0/
  + OpenSSL library is not used
  + md5 library is not used
  + using system zlib library


==========================
Настройки
==========================

worker_processes  6;
events {
	connections  1024;
}
sendfile        on;
tcp_nodelay     on;

keepalive_timeout  60;
gzip_http_version 1.1;
gzip             on;
gzip_min_length  1100;
gzip_buffers     4 8k;
gzip_types       text/plain text/html text/xml;
gzip_proxied     expired no-cache no-store private auth no_last_modified
no_etag;


log_format  main    '%addr - - [%time] "%request" %status %length';

server {
	listen 195.42.181.71:80;
	server_name www.fictionbook.ru fictionbook.ru lib.fictionbook.ru
fictionbook.lib.ru;
	access_log      /var/nginx/fictionbook_access.log main;
	location ~ ^/[^\/\.]+\.(txt|css|gif|ico|js|jpg)$ {
		root    /usr/www/fictionbook.lib;
		charset         off;
		expires         30d;
		access_log      off;
	}
	location / {
		proxy_pass  http://127.0.0.1:82/;
		proxy_redirect     off;
		proxy_connect_timeout      90;
		proxy_send_timeout         90;
		proxy_read_timeout         90;
		
		proxy_header_buffer_size   32k;
		proxy_buffers              2000 32k;
		proxy_busy_buffers_size    64k;
		
		
		proxy_set_header  X-Forwarded-For
$proxy_add_x_forwarded_for;
		client_max_body_size       3m;
		client_body_buffer_size    128k;
	}
}