Автор Тема: Apache 2.2.15 Init: Seeding PRNG with 144 bytes of entropy  (Прочетена 3909 пъти)

divak

  • Напреднали
  • *****
  • Публикации: 829
    • Профил
Здравейте,
След ъпгрейд на 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>

Ако някой се е сблъсквал с този проблем нека сподели.
Активен

neter

  • Global Moderator
  • Напреднали
  • *****
  • Публикации: 3408
  • Distribution: Debian, SailfishOS, CentOS
  • Window Manager: LXDE, Lipstick
    • Профил
    • WWW
Re: Apache 2.2.15 Init: Seeding PRNG with 144 bytes of entropy
« Отговор #1 -: Jun 08, 2012, 14:57 »
Ползваш ли сертификати за нещо? Дай пълен списък на модулите, които си заредил, и по-голяма част от конфигурацията на Apache. Тук пише за бъг, който се е проявявал при използване на mod_proxy с mod_nss, и макар че е поправен с излизането на 6.0, може пак да се е проявил с излизането на 6.2. А защо са ти едновременно и mod_nss, и mod_ssl? По принцип могат да работят заедно, но някои модули, които работят с SSL, може да се объркат. Такъв е и споменатият по-горе mod_proxy, който, поради единичното си API за SSL, не успява да комуникира с mod_nss, когато mod_ssl е зареден. А може и да е някакъв проблем със сертификата. Ако ползваш такъв, купил ли си го или е самоподписан? Ако е самоподписан, как го създаде?
Активен

"Да си добре приспособен към болно общество не е признак за добро здраве" - Джиду Кришнамурти

gat3way

  • Напреднали
  • *****
  • Публикации: 6050
  • Relentless troll
    • Профил
    • WWW
Re: Apache 2.2.15 Init: Seeding PRNG with 144 bytes of entropy
« Отговор #2 -: Jun 08, 2012, 16:21 »
Къде точно видя проблем?
Активен

"Knowledge is power" - France is Bacon

neter

  • Global Moderator
  • Напреднали
  • *****
  • Публикации: 3408
  • Distribution: Debian, SailfishOS, CentOS
  • Window Manager: LXDE, Lipstick
    • Профил
    • WWW
Re: Apache 2.2.15 Init: Seeding PRNG with 144 bytes of entropy
« Отговор #3 -: Jun 08, 2012, 16:56 »
Хмм... всъщност гледам, че сам по себе си този ред не е проблем, а само указател за задаването на начална стойност на генератора на псевдослучайни числа за SSL handshake-а. Но пък ми се вижда странно защо влиза в error лога, а не в access лога. А пък не се виждат грешки в дадения лог... Може и да няма проблем, а аз да съм се хвърлил в грешна посока :)
« Последна редакция: Jun 08, 2012, 17:04 от neter »
Активен

"Да си добре приспособен към болно общество не е признак за добро здраве" - Джиду Кришнамурти

divak

  • Напреднали
  • *****
  • Публикации: 829
    • Профил
Re: Apache 2.2.15 Init: Seeding PRNG with 144 bytes of entropy
« Отговор #4 -: 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. На тази машина сертификата е самоподписан.
Другата седмица ще пусна повече инфо за машината.
Активен

romeo_ninov

  • Напреднали
  • *****
  • Публикации: 2155
    • Профил
Re: Apache 2.2.15 Init: Seeding PRNG with 144 bytes of entropy
« Отговор #5 -: Jun 08, 2012, 21:30 »
Хвърлете едно око на това: http://egd.sourceforge.net/
Активен

0x2B|~0x2B

gat3way

  • Напреднали
  • *****
  • Публикации: 6050
  • Relentless troll
    • Профил
    • WWW
Re: Apache 2.2.15 Init: Seeding PRNG with 144 bytes of entropy
« Отговор #6 -: Jun 09, 2012, 00:55 »
Да, единственият проблем е че това нещо влиза в лога въобще. Оттам нататък не виждам нищо проблемно - това е каквото се очаква от mod_ssl.

Нещата разбира се са доста по-сложни и имат доста частни случаи, ще се опитам да го обясня по много прост начин. Когато някой иска да си говори с твоя SSL сървър, има два важни момента - автентикация и поверителност. Автентикацията на практика липсва със самоподписания сертификат, но поверителността е налице - някой който слухти пасивно трафика, няма как да го декриптира. За да стане това възможно, трябва двете страни които си говорят да имат общ ключ за криптиране/декриптиране на трафика, който е известен само на тях. Тук е магията - и за да избегна всякаква математика, представи си следното - двете страни имат една палитра с боички и четка. Двете страни искат да си обменят някакъв лист намацан с цвят за който само двете знаят, така че всеки който гледа какво и обменят да не може да види и разбере какъв е този цвят на листа. Та прави се следното - двете страни се сдоговарят за общ, публичен цвят (да речем жълт) и си избират на случаен принцип техен личен си, секретен цвят (да речем едната страна си избере червен, другата си избере син). След като се разберат за общия жълт цвят, двете страни смесват на един лист общия с тайния цвят - едната страна ще смеси жълтия с червен и ще получи оранжев, другата ще смеси жълтия със син и ще получи зелен. Получените мацаници си ги разменят. Този дето гледа отстрани ще види как си разменят лист с оранжев и зелен цвят. Сега когато го получат, двете страни смесват получената мацаница с тайния си цвят - едната смесва оранжевото със синьо и получава кафяво, другата смесва зеленото с червено и пак получава кафяво - и ето, двете страни си имат споделен абсолютно еднакъв цвят - лайняно-кафяв.

Примерът би следвало да е малко по-успешен ако имаш примерно по 10 разцветки на зеленото, червеното, жълтото и т.н. и си избираш на случаен принцип. Само че как да си избереш на случаен принцип - да речем хвърляш зарчета.


След това дълго лирическо отклонение, да се върнем в реалния свят, където боички не се смесват, а се извършват операции по вдигане на степен modulo нещо си, при това с доста големи числа. Хвърлянето на зарчета за да си избереш боичка, всъщност е четене от /dev/random на 144 байта, които задават началното състояние на друга функция, даваща въпросните големи случайни числа които се вдигат на степен и се търси резултата modulo нещо си. Това е т.нар. Diffie-Hellman key exhange, който не сам по себе си, но в комбинация с други алгоритми е най-често срещания начин двете страни на SSL комуникацията да си разменят таен, известен само на тях ключ. А това което получаваш в лога е еквивалента на "хвърлих 144 пъти зара за да си взема начална случайна стойност". И е ама съвсем в реда на нещата. Това което не е в реда на нещата е да бъдеш информиран за това събитие, защото е нещо съвсем тривиално.


И така обяснено по малоумен начин...
Активен

"Knowledge is power" - France is Bacon

divak

  • Напреднали
  • *****
  • Публикации: 829
    • Профил
Re: Apache 2.2.15 Init: Seeding PRNG with 144 bytes of entropy
« Отговор #7 -: 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.
За сега нещата се крепят, тестовете минават.
Благодаря на всички които дадоха мнение и ми помогнаха с насоки.
Активен

divak

  • Напреднали
  • *****
  • Публикации: 829
    • Профил
Re: Apache 2.2.15 Init: Seeding PRNG with 144 bytes of entropy
« Отговор #8 -: 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 но тя като цяло е на сериозни машини и там нещата са друга бира.
Това е творението за което става на въпрос.
Ако някой има идея с какво или друг метод за стрес натоварване нека сподели.

Активен

Подобни теми
Заглавие Започната от Отговора Прегледи Последна публикация
cbq.init
Настройка на програми
jud 1 1839 Последна публикация Apr 08, 2002, 09:30
от
INIT
Хардуерни и софтуерни проблеми
ivo3d 7 1939 Последна публикация May 02, 2003, 23:11
от
cbq.init 0.72
Хардуерни и софтуерни проблеми
kris_p 5 1895 Последна публикация May 25, 2004, 21:27
от vladou
cbq.init help
Настройка на програми
Unseen 5 1547 Последна публикация Jun 04, 2004, 18:37
от Unseen
cbq.init
Настройка на програми
mozly 0 850 Последна публикация Jul 19, 2004, 17:14
от mozly