Титла: Apache 2.2.15 Init: Seeding PRNG with 144 bytes of entropy Публикувано от: divak в Jun 08, 2012, 14:05 Здравейте,
След ъпгрейд на RHEL 6.1 на RHEL 6.2, във error_log на Apache 2.2.15 се появиха следните съобщения: [info] Init: Seeding PRNG with 144 bytes of entropy [info] Init: Seeding PRNG with 144 bytes of entropy . . . . Инфо за сървъра: Apache/2.2.15 (Unix) mod_nss/2.2.15 NSS/3.13.1.0 PHP/5.3.3 mod_ssl/2.2.15 OpenSSL/1.0.0-fips mod_jk/1.2.31 Server version: Apache/2.2.15 (Unix) Server built: Feb 7 2012 09:50:11 Server's Module Magic Number: 20051115:24 Server loaded: APR 1.3.9, APR-Util 1.3.9 Compiled using: APR 1.3.9, APR-Util 1.3.9 Architecture: 64-bit Server MPM: Prefork threaded: no forked: yes (variable process count) Server compiled with.... -D APACHE_MPM_DIR="server/mpm/prefork" -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_SYSVSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D DYNAMIC_MODULE_LIMIT=128 -D HTTPD_ROOT="/etc/httpd" -D SUEXEC_BIN="/usr/sbin/suexec" -D DEFAULT_PIDLOG="run/httpd.pid" -D DEFAULT_SCOREBOARD="logs/apache_runtime_status" -D DEFAULT_LOCKFILE="logs/accept.lock" -D DEFAULT_ERRORLOG="logs/error_log" -D AP_TYPES_CONFIG_FILE="conf/mime.types" -D SERVER_CONFIG_FILE="conf/httpd.conf" и инфо от конфа: =================================================== <IfModule prefork.c> StartServers 1000 MinSpareServers 1000 MaxSpareServers 1500 ServerLimit 2000 MaxClients 2000 MaxRequestsPerChild 4000 </IfModule> <IfModule worker.c> StartServers 42 ServerLimit 42 MaxClients 1152 MinSpareThreads 32 MaxSpareThreads 128 ThreadsPerChild 64 MaxRequestsPerChild 0 </IfModule> Ако някой се е сблъсквал с този проблем нека сподели. Титла: Re: Apache 2.2.15 Init: Seeding PRNG with 144 bytes of entropy Публикувано от: neter в Jun 08, 2012, 14:57 Ползваш ли сертификати за нещо? Дай пълен списък на модулите, които си заредил, и по-голяма част от конфигурацията на Apache. Тук ($2) пише за бъг, който се е проявявал при използване на mod_proxy с mod_nss, и макар че е поправен с излизането на 6.0, може пак да се е проявил с излизането на 6.2. А защо са ти едновременно и mod_nss, и mod_ssl? По принцип могат да работят заедно, но някои модули, които работят с SSL, може да се объркат. Такъв е и споменатият по-горе mod_proxy, който, поради единичното си API за SSL, не успява да комуникира с mod_nss, когато mod_ssl е зареден. А може и да е някакъв проблем със сертификата. Ако ползваш такъв, купил ли си го или е самоподписан? Ако е самоподписан, как го създаде?
Титла: Re: Apache 2.2.15 Init: Seeding PRNG with 144 bytes of entropy Публикувано от: gat3way в Jun 08, 2012, 16:21 Къде точно видя проблем?
Титла: Re: Apache 2.2.15 Init: Seeding PRNG with 144 bytes of entropy Публикувано от: neter в Jun 08, 2012, 16:56 Хмм... всъщност гледам, че сам по себе си този ред не е проблем, а само указател за задаването на начална стойност на генератора на псевдослучайни числа за SSL handshake-а. Но пък ми се вижда странно защо влиза в error лога, а не в access лога. А пък не се виждат грешки в дадения лог... Може и да няма проблем, а аз да съм се хвърлил в грешна посока :)
Титла: Re: Apache 2.2.15 Init: Seeding PRNG with 144 bytes of entropy Публикувано от: divak в Jun 08, 2012, 17:18 Здравейте,
Нямам много време, но накратко ще ви резюмирам проблема: Loaded Modules: core_module (static) mpm_prefork_module (static) http_module (static) so_module (static) authz_host_module (shared) authz_default_module (shared) log_config_module (shared) expires_module (shared) deflate_module (shared) headers_module (shared) setenvif_module (shared) mime_module (shared) status_module (shared) autoindex_module (shared) negotiation_module (shared) dir_module (shared) speling_module (shared) alias_module (shared) rewrite_module (shared) security2_module (shared) unique_id_module (shared) nss_module (shared) php5_module (shared) ssl_module (shared) jk_module (shared) Syntax OK Машината е тестова на продъкшън. Апача ползва ssl и след него има Tomcat и след него UCM. На тази машина сертификата е самоподписан. Другата седмица ще пусна повече инфо за машината. Титла: Re: Apache 2.2.15 Init: Seeding PRNG with 144 bytes of entropy Публикувано от: romeo_ninov в Jun 08, 2012, 21:30 Хвърлете едно око на това: http://egd.sourceforge.net/
Титла: Re: Apache 2.2.15 Init: Seeding PRNG with 144 bytes of entropy Публикувано от: gat3way в Jun 09, 2012, 00:55 Да, единственият проблем е че това нещо влиза в лога въобще. Оттам нататък не виждам нищо проблемно - това е каквото се очаква от mod_ssl.
Нещата разбира се са доста по-сложни и имат доста частни случаи, ще се опитам да го обясня по много прост начин. Когато някой иска да си говори с твоя SSL сървър, има два важни момента - автентикация и поверителност. Автентикацията на практика липсва със самоподписания сертификат, но поверителността е налице - някой който слухти пасивно трафика, няма как да го декриптира. За да стане това възможно, трябва двете страни които си говорят да имат общ ключ за криптиране/декриптиране на трафика, който е известен само на тях. Тук е магията - и за да избегна всякаква математика, представи си следното - двете страни имат една палитра с боички и четка. Двете страни искат да си обменят някакъв лист намацан с цвят за който само двете знаят, така че всеки който гледа какво и обменят да не може да види и разбере какъв е този цвят на листа. Та прави се следното - двете страни се сдоговарят за общ, публичен цвят (да речем жълт) и си избират на случаен принцип техен личен си, секретен цвят (да речем едната страна си избере червен, другата си избере син). След като се разберат за общия жълт цвят, двете страни смесват на един лист общия с тайния цвят - едната страна ще смеси жълтия с червен и ще получи оранжев, другата ще смеси жълтия със син и ще получи зелен. Получените мацаници си ги разменят. Този дето гледа отстрани ще види как си разменят лист с оранжев и зелен цвят. Сега когато го получат, двете страни смесват получената мацаница с тайния си цвят - едната смесва оранжевото със синьо и получава кафяво, другата смесва зеленото с червено и пак получава кафяво - и ето, двете страни си имат споделен абсолютно еднакъв цвят - лайняно-кафяв. Примерът би следвало да е малко по-успешен ако имаш примерно по 10 разцветки на зеленото, червеното, жълтото и т.н. и си избираш на случаен принцип. Само че как да си избереш на случаен принцип - да речем хвърляш зарчета. След това дълго лирическо отклонение, да се върнем в реалния свят, където боички не се смесват, а се извършват операции по вдигане на степен modulo нещо си, при това с доста големи числа. Хвърлянето на зарчета за да си избереш боичка, всъщност е четене от /dev/random на 144 байта, които задават началното състояние на друга функция, даваща въпросните големи случайни числа които се вдигат на степен и се търси резултата modulo нещо си. Това е т.нар. Diffie-Hellman key exhange, който не сам по себе си, но в комбинация с други алгоритми е най-често срещания начин двете страни на SSL комуникацията да си разменят таен, известен само на тях ключ. А това което получаваш в лога е еквивалента на "хвърлих 144 пъти зара за да си взема начална случайна стойност". И е ама съвсем в реда на нещата. Това което не е в реда на нещата е да бъдеш информиран за това събитие, защото е нещо съвсем тривиално. И така обяснено по малоумен начин... Титла: Re: Apache 2.2.15 Init: Seeding PRNG with 144 bytes of entropy Публикувано от: divak в Jun 11, 2012, 17:20 Здравейте,
За сега махнах модули които не ползвам. Loaded Modules: core_module (static) mpm_prefork_module (static) http_module (static) so_module (static) authz_host_module (shared) authz_default_module (shared) log_config_module (shared) expires_module (shared) deflate_module (shared) headers_module (shared) setenvif_module (shared) mime_module (shared) status_module (shared) autoindex_module (shared) negotiation_module (shared) dir_module (shared) speling_module (shared) alias_module (shared) rewrite_module (shared) security2_module (shared) unique_id_module (shared) ssl_module (shared) jk_module (shared) Syntax OK И за сега нещата се оправиха. Махна се инфо реда във error_log -a. Тоест махнах модула: nss_module. За сега нещата се крепят, тестовете минават. Благодаря на всички които дадоха мнение и ми помогнаха с насоки. Титла: Re: Apache 2.2.15 Init: Seeding PRNG with 144 bytes of entropy Публикувано от: divak в Jun 22, 2012, 17:28 Здравейте,
Тъй като ставаше на въпрос за сериозни натоварвания на apache/tomcat/UCM мисля да споделя малко резултати, и ако някой иска да обсъдим и евентуални "тунингования" на подобна система. Заради специфичноста на проекта ще спестя имената : Та, поради ефективноста на MPM worker за Apache 2.x направих следните параметри: <IfModule worker.c> StartServers 42 ServerLimit 95 MaxClients 966 MinSpareThreads 42 MaxSpareThreads 95 ThreadsPerChild 42 MaxRequestsPerChild 1000 </IfModule> Това е оразмерявано по параметрите на машината (виртуална) : CPU - 4 RAM - 4 GB Linux version 2.6.32-220.el6.x86_64 Дисковете са масив на сторидж Loaded Modules: core_module (static) mpm_prefork_module (static) http_module (static) so_module (static) authz_host_module (shared) authz_default_module (shared) log_config_module (shared) expires_module (shared) deflate_module (shared) headers_module (shared) setenvif_module (shared) mime_module (shared) status_module (shared) autoindex_module (shared) negotiation_module (shared) dir_module (shared) speling_module (shared) alias_module (shared) security2_module (shared) unique_id_module (shared) ssl_module (shared) jk_module (shared) Syntax OK Резултата от теста: ab -n 10000 -c 700 https://tst2/page/default.aspx?xml_id=/bg-BG/.loginAll This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking tst2(be patient) Completed 1000 requests Completed 2000 requests Completed 3000 requests Completed 4000 requests Completed 5000 requests Completed 6000 requests Completed 7000 requests Completed 8000 requests Completed 9000 requests Completed 10000 requests Finished 10000 requests Server Software: Apache/2.2.15 Server Hostname: tst2 Server Port: 443 SSL/TLS Protocol: TLSv1/SSLv3,DHE-RSA-AES256-SHA,2048,256 Document Path: /page/default.aspx?xml_id=/bg-BG/.loginAll Document Length: 26894 bytes Concurrency Level: 700 Time taken for tests: 300.252 seconds Complete requests: 10000 Failed requests: 0 Write errors: 0 Total transferred: 271916985 bytes HTML transferred: 269779530 bytes Requests per second: 33.31 [#/sec] (mean) Time per request: 21017.633 [ms] (mean) Time per request: 30.025 [ms] (mean, across all concurrent requests) Transfer rate: 884.40 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 31 6121 3067.1 6606 24037 Processing: 2027 14758 3409.2 14111 25453 Waiting: 452 6443 6174.1 3179 24689 Total: 9041 20879 3844.1 20419 48713 Percentage of the requests served within a certain time (ms) 50% 20419 66% 20913 75% 21499 80% 21900 90% 23872 95% 25911 98% 34090 99% 37450 100% 48713 (longest request) top - 11:23:39 up 6 days, 20:01, 3 users, load average: 4.28, 5.92, 5.91 Tasks: 243 total, 3 running, 240 sleeping, 0 stopped, 0 zombie Cpu(s): 62.9%us, 4.3%sy, 0.0%ni, 30.6%id, 0.1%wa, 0.6%hi, 1.6%si, 0.0%st Mem: 3924924k total, 3459352k used, 465572k free, 3868k buffers Swap: 6160376k total, 85744k used, 6074632k free, 67620k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 12927 root 20 0 553m 487m 2620 R 55.6 12.7 1:06.68 ab 13377 apache 20 0 2572m 84m 2708 S 18.5 2.2 0:12.18 httpd.worker 15855 apache 20 0 2572m 84m 2704 S 17.9 2.2 0:09.11 httpd.worker 13513 apache 20 0 2636m 84m 2708 S 17.6 2.2 0:11.62 httpd.worker 15544 apache 20 0 2572m 82m 2708 S 17.6 2.1 0:09.73 httpd.worker 16951 apache 20 0 2572m 79m 2708 S 17.6 2.1 0:06.02 httpd.worker 17932 apache 20 0 2572m 79m 2692 S 17.6 2.1 0:02.01 httpd.worker 14487 apache 20 0 2572m 84m 2708 S 16.9 2.2 0:11.02 httpd.worker 18229 apache 20 0 2636m 78m 2616 S 16.3 2.0 0:01.24 httpd.worker 30472 tomcat 20 0 3456m 255m 6148 S 8.8 6.7 3:59.02 java 30264 tomcat 20 0 3453m 210m 6144 S 8.1 5.5 3:49.74 java 18335 apache 20 0 1315m 46m 1816 S 7.5 1.2 0:00.23 httpd.worker 30369 tomcat 20 0 3455m 235m 6132 S 7.5 6.1 4:03.62 java 31094 tomcat 20 0 3456m 258m 6156 S 7.5 6.7 3:55.09 java 30159 tomcat 20 0 3456m 238m 6132 S 7.2 6.2 3:58.25 java 30575 tomcat 20 0 3465m 222m 6140 S 7.2 5.8 4:06.13 java 30781 tomcat 20 0 3454m 211m 6132 S 7.2 5.5 3:55.03 java 30678 tomcat 20 0 3453m 193m 6132 S 6.8 5.1 3:59.23 java 30884 tomcat 20 0 3456m 210m 6140 S 6.8 5.5 4:04.29 java 30991 tomcat 20 0 3458m 208m 6132 S 6.8 5.4 3:56.23 java Зад Apache са конфигурирани томкети които равномерно разпределят заявките, за да може да се разпредели натоварването и да не се получава невъзможност за обработка породена от ограниченията на java vm. Като цяло това е системата (спестявам часта - tomcat-UCM), издържа на натоварвания без да припадат нито apache и tomcat, базата след тях е oracle 11 но тя като цяло е на сериозни машини и там нещата са друга бира. Това е творението за което става на въпрос. Ако някой има идея с какво или друг метод за стрес натоварване нека сподели. |