{"id":958,"date":"2014-08-09T17:52:59","date_gmt":"2014-08-09T20:52:59","guid":{"rendered":"http:\/\/www.viazap.com.br\/?p=958"},"modified":"2014-08-09T17:52:59","modified_gmt":"2014-08-09T20:52:59","slug":"apache-2-4-modulos-de-multiprocessamento","status":"publish","type":"post","link":"https:\/\/blog.clusterweb.com.br\/?p=958","title":{"rendered":"Apache 2.4 – M\u00f3dulos de Multiprocessamento"},"content":{"rendered":"\n\n\n\n\n\n
Conceitos b\u00e1sicos<\/b><\/p>\n
\n

Apache<\/em>\u00a0\u00e9 um servidor WEB (HTTPD) portado para v\u00e1rias plataformas e ambientes. O servidor WEB Apache pode ser executado em\u00a0GNU\/Linux<\/a>, Windows, Netware ou OS\/2. Para comportar essa flexibilidade de ambientes, Apache adota um projeto modular que permite ao webmaster escolher, entre um conjunto de funcionalidades, quais ser\u00e3o ativadas ou desativadas.<\/p>\n

Os m\u00f3dulos s\u00e3o implementados de duas maneiras: est\u00e1ticos ou din\u00e2micos:<\/p>\n

MPM prefork<\/b><\/p>\n
\n
\n

O m\u00f3dulo prefork implementa um servidor HTTPD n\u00e3o-thread. Cada requisi\u00e7\u00e3o HTTP \u00e9 atendida por um processo individual criado a partir de um fork. Isso pode ser \u00fatil para aplica\u00e7\u00f5es WEB que n\u00e3o aceitam ou n\u00e3o sabem trabalhar com threads de modo seguro.<\/p>\n

Outra raz\u00e3o \u00e9 o melhor isolamento evitando que um processo errante contamine e derrube o servidor. Isso pode ser \u00fatil at\u00e9 que sua aplica\u00e7\u00e3o esteja em um estado maduro para trabalhar com threads.<\/p>\n

Esse m\u00f3dulo se auto regula, dessa maneira, raramente, \u00e9 preciso fazer ajustes no valor padr\u00e3o de seus par\u00e2metros. O principal par\u00e2metro \u00e9 MaxRequestWorks, que deve ser grande o suficiente para manipular o n\u00famero de requisi\u00e7\u00f5es que o servidor ir\u00e1 receber, mas pequeno o suficiente para n\u00e3o exaurir seus recursos de hardware. Vejamos como esse m\u00f3dulo funciona na pr\u00e1tica.<\/p>\n

Um processo pai (httpd ou apache2) mant\u00e9m sempre um certo n\u00famero de processos filhos ouvindo por requisi\u00e7\u00f5es HTTP na porta TCP\/80. Esses processos s\u00e3o chamados de spare (reserva) ou de processos idle (desocupados). Quando uma requisi\u00e7\u00e3o HTTP chega pela rede, eles devem estar prontos para atender. Isso evita que as requisi\u00e7\u00f5es precisem esperar que o servidor realize o fork para criar novos processos filhos, pois em termos de computa\u00e7\u00e3o, esse \u00e9 um tempo grande.<\/p>\n

Um conjunto de diretivas configura como o processo pai cria seus processos filhos. Na maioria dos sites o valor padr\u00e3o \u00e9 suficiente para obter o equil\u00edbrio entre demanda e disponibilidade de recursos de hardware. De acordo com o manual do Apache 2.4, se um site precisa atender mais de 256 requisi\u00e7\u00f5es simult\u00e2neas \u00e9 preciso fazer ajustes manuais nesses par\u00e2metros at\u00e9 encontrar o equil\u00edbrio desejado.<\/p>\n

Enquanto o processo pai (daemon) necessita de privil\u00e9gios de administrador (root), os processos filhos s\u00e3o lan\u00e7ados com os privil\u00e9gios de um usu\u00e1rio comum (no Debian, esse usu\u00e1rio se chama www-data). As diretivas User e Group definem esse usu\u00e1rio comum. Isso \u00e9 v\u00e1lido para\u00a0prefork,\u00a0worker\u00a0e\u00a0event.<\/p>\n

O privil\u00e9gio de leitura (read) no sistema de arquivos, deve ser garantido ao conte\u00fado que esse usu\u00e1rio comum ir\u00e1 fornecer; os demais privil\u00e9gios devem ser mantidos ao m\u00ednimo necess\u00e1rio. Vejamos como as principais diretivas de prefork devem ser configuradas.<\/p>\n

MaxSpareServers – define o n\u00famero m\u00e1ximo de processos spare. O valor padr\u00e3o \u00e9 10. Se o n\u00famero de processos spare exceder o valor definido para essa diretiva (ap\u00f3s a libera\u00e7\u00e3o de um processo que estava ocupado) o servidor ir\u00e1 matar esses processos excedentes (isso tem um alto custo computacional, tenha cuidado!). O menor valor aceito para esse argumento \u00e9 SEMPRE gerado por MinSpareServers + 1.<\/p>\n

MinSpareServers\u00a0– n\u00famero m\u00ednimo de processos spare mantidos pelo servidor. O valor padr\u00e3o \u00e9 5. Se o n\u00famero de processos spare ficar abaixo do valor definido nesse par\u00e2metro, o servidor lan\u00e7ar\u00e1 novos processos-filhos at\u00e9 atingir o valor informado nessa diretiva. Esse processo de lan\u00e7ar forks, ocorrer\u00e1 de forma exponencial e com intervalos de um segundo, at\u00e9 atingir o valor de 32 processos lan\u00e7ados simultaneamente ou at\u00e9 atingir o valor m\u00ednimo definido na diretiva.<\/p>\n

Assim, o servidor lan\u00e7a um processo, aguarda um segundo e lan\u00e7a dois processos. Aguarda outro segundo e lan\u00e7a quatro processos, sucessivamente at\u00e9 lan\u00e7ar 32 processos simultaneamente ou atingir o valor m\u00ednimo de spares definido na diretiva, o que acontecer primeiro.<\/p>\n

StartServers\u00a0– define o n\u00famero de processos filhos lan\u00e7ados no momento da inicializa\u00e7\u00e3o do servidor HTTPD. Essa diretiva \u00e9 comum para os m\u00f3dulos\u00a0prefork,\u00a0worker\u00a0ou\u00a0event. Esse par\u00e2metro permite um balanceamento entre os valores m\u00ednimos e m\u00e1ximos.<\/p>\n

O valor padr\u00e3o ir\u00e1 variar entre os diferentes MPMs devido as diferen\u00e7as de funcionamento entre eles. Para o m\u00e9todo\u00a0prefork, esse valor \u00e9 5. Observe que esse valor deve estar entre os valores m\u00ednimo e m\u00e1ximo.<\/p>\n

A inclus\u00e3o dessas diretivas em um arquivo de configura\u00e7\u00e3o, ficaria do seguinte modo:<\/p>\n

MPM worker<\/b><\/p>\n
\n

Essa MPM implementa um servidor multiprocesso e multithread. Utilizando threads \u00e9 poss\u00edvel atender mais solicita\u00e7\u00f5es HTTP com menos processos e, deste modo, consumir menos recursos de hardware. No modo worker, os processos-filhos t\u00eam capacidade de lan\u00e7ar v\u00e1rios threads que ouvem por requisi\u00e7\u00f5es.<\/p>\n

Isso mant\u00e9m a estabilidade do sistema isolando as requisi\u00e7\u00f5es em cada processo filho e seus v\u00e1rios threads. Caso uma aplica\u00e7\u00e3o errante derrube um processo-filho, o servidor ainda \u00e9 capaz de continuar atendendo requisi\u00e7\u00f5es atrav\u00e9s de outros processos-filhos e seus threads.<\/p>\n

A mais importante diretiva utilizada pelo m\u00e9todo Worker \u00e9 ThreadsPerChild, que controla o n\u00famero de threads lan\u00e7ados por processo. Vejamos como esse m\u00f3dulo funciona na pr\u00e1tica.<\/p>\n

Um processo pai (daemon) \u00e9 respons\u00e1vel por lan\u00e7ar processos filhos. Cada um desses processos filhos cria um certo n\u00famero de servidores HTTP que se apresentam na forma de threads. S\u00e3o os threads que ouvem pelas conex\u00f5es e quando elas chegam, eles passam o controle para o seu processo pai.<\/p>\n

Apache ir\u00e1 manter um conjunto de threads spare ou threads idle, evitando que a requisi\u00e7\u00e3o HTTP tenha que esperar pela cria\u00e7\u00e3o do thread que ir\u00e1 atend\u00ea-la. O n\u00famero de processos inicialmente lan\u00e7ados, \u00e9 definido na diretiva StartServers. Observe que em rela\u00e7\u00e3o ao m\u00f3dulo prefork esse valor \u00e9 sempre menor, pois cada processo lan\u00e7ar\u00e1 v\u00e1rios threads compensando o n\u00famero menor de processos em v\u00e1rias vezes.<\/p>\n

O servidor HTTPD avalia o n\u00famero de threads ociosos de todos os processos e baseado nos valores de MinSpareThreads e MaxSpareThreads, o servidor decidir\u00e1 por lan\u00e7ar ou matar processos. Apache gerencia esses valores automaticamente e de modo satisfat\u00f3rio para sites que n\u00e3o s\u00e3o movimentados.<\/p>\n

Para sites que atendem muitas requisi\u00e7\u00f5es, o ajuste manual \u00e9 necess\u00e1rio. A diretiva MaxRequestWorkers define o n\u00famero m\u00e1ximo de threads permitidos em todos os processos filhos. O n\u00famero m\u00e1ximo de processos filhos \u00e9 definido pela divis\u00e3o do valor de MaxRequestWorkers por ThreadsPerChild.<\/p>\n

Duas diretivas definem o limite hard do n\u00famero de processos filhos e servidores de threads em um processo filho. Essas diretivas somente podem ser modificadas com a parada total do servi\u00e7o. A diretiva ServerLimit define um limite hard para o n\u00famero de processos filhos e deve ser maior ou igual ao valor definido para MaxRequestWorkers dividido por ThreadsPerChild.<\/p>\n

A diretiva ThreadLimit \u00e9 um limite hard para o n\u00famero de servidores de threads e deve ser maior ou igual \u00e0 diretiva ThreadsPerChild.<\/p>\n

Independente do conjunto de processos filhos, pode haver alguns processos que s\u00e3o terminados e um de seus threads ainda est\u00e1 ativo lidando com uma conex\u00e3o. O valor da diretiva MaxRequestWorkers (define o n\u00famero m\u00e1ximo de conex\u00f5es simult\u00e2neas), pode interferir bloqueando novos processos, pois entende que o thread est\u00e1 ativo.<\/p>\n

Para evitar esse comportamento, desabilite o t\u00e9rmino de processos-filhos definindo o valor de MaxConnectionPerChild para zero e deixe os valores de MaxSpareThreads e MaxRequestWorkers, iguais. A configura\u00e7\u00e3o padr\u00e3o para o m\u00f3dulo worker \u00e9:<\/p>\n

 ServerLimit         16\r\n StartServers        2\r\n MaxRequestWorkers   400\r\n MinSpareThreads     75\r\n MaxSpareThreads     250\r\n ThreadsPerChild     25\r\n<\/pre>\n
A menos que\u00a0suexec\u00a0esteja sendo utilizado, essas diretivas v\u00e3o configurar os privil\u00e9gios com que\u00a0scripts CGI\u00a0s\u00e3o executados.<\/p>\n
A diretiva\u00a0MaxConnectionsPerChild\u00a0controla a frequ\u00eancia com que os processos s\u00e3o reciclados, matando processos velhos e lan\u00e7ando novos. Isso \u00e9 uma fun\u00e7\u00e3o de seguran\u00e7a do sistema.<\/p>\n
A MPM worker utiliza um Mutex (mpm-accept) para criar uma lista com as requisi\u00e7\u00f5es que chegam. Consulte a documenta\u00e7\u00e3o para saber como ajustar o valor do mutex.<\/p>\n
Diretivas para worker:<\/p>\n
ServerLimit\u00a0– \u00e9 uma diretiva comum em prefork, worker ou event utilizada para definir o limite superior do n\u00famero de processos. Em worker essa diretiva, em combina\u00e7\u00e3o com ThreadLimit configura o valor m\u00e1ximo de MaxRequestWorkers definindo o tempo de vida \u00fatil de um processo HTTPD. Essa diretiva n\u00e3o pode ser reconfigurada em tempo de execu\u00e7\u00e3o. Se o valor dessa diretiva e MaxRequestWorkers forem definidos de forma muito alta haver\u00e1 um grande consumo de mem\u00f3ria compartilhada de modo que o sistema pode n\u00e3o conseguir manipular, se tornando inst\u00e1vel, ou at\u00e9 impedindo o servi\u00e7o HTTPD de ser inicializado. O valor padr\u00e3o para essa diretiva \u00e9 16.<\/p>\n
StartServers\u00a0– \u00e9 uma diretiva comum em prefork, worker ou event utilizada para definir o n\u00famero de processos filhos criados no momento da inicializa\u00e7\u00e3o. O padr\u00e3o para worker \u00e9 3.<\/p>\n
MaxRequestWorkers\u00a0– \u00e9 uma diretiva comum em prefork, worker ou event utilizada para definir o n\u00famero m\u00e1ximo de conex\u00f5es que s\u00e3o processadas simultaneamente. Qualquer requisi\u00e7\u00e3o que chegar, ap\u00f3s esse valor ser atingido, ser\u00e1 colocada em uma fila de espera. Isso ocorrer\u00e1 at\u00e9 atingir o valor definido em ListenBackLog, que define o tamanho da fila. Acima desse valor as requisi\u00e7\u00f5es s\u00e3o descartadas. As requisi\u00e7\u00f5es da fila s\u00e3o atendidas t\u00e3o logo um thread seja liberado por sua ordem de chegada. Para prefork esse valor \u00e9 256. Para worker e event \u00e9 definido pelo valor de ServerLimit multiplicado por ThreadsPerChild. Esses valores devem ser mutuamente atualizados para evitar erros.<\/p>\n
MinSpareThreads\u00a0– define o n\u00famero m\u00ednimo de threads ociosos para lidar com requisi\u00e7\u00f5es entrantes. Comum em worker e event. Esse valor \u00e9 medido para todo o servidor. Se o n\u00famero de threads for inferior ao valor definido, ent\u00e3o, o servidor pode gerar processos filhos para atender esse valor.<\/p>\n
MaxSpareThreads\u00a0– essa diretiva \u00e9 comum para worker e event. \u00c9 utilizada para definir o valor do n\u00famero m\u00e1ximo de threads ociosos. Se houver mais threads ociosos que o valor dessa diretiva, ent\u00e3o, processos filhos ser\u00e3o mortos at\u00e9 ser menor que esse valor. Apache ir\u00e1 corrigir o valor informado aqui de acordo com a seguinte regra. O valor deve ser maior ou igual a soma de MinSpareThreads e ThreadsPerChild.<\/p>\n
ThreadsPerChild\u00a0– essa \u00e9 uma diretiva comum a worker e event, utilizada para definir o n\u00famero de threads criados por cada processo filho. O processo filho cria esses threads no momento de sua cria\u00e7\u00e3o e n\u00e3o cria mais threads depois. O valor padr\u00e3o \u00e9 25. O total de threads deve ser suficiente para comportar a carga de requisi\u00e7\u00f5es recebida pelo servidor.<\/p>\n<\/div>\n<\/td>\n<\/tr>\n
MPM event<\/b><\/p>\n
\n

Esse MPM \u00e9 uma variante de worker, elaborada para permitir mais requisi\u00e7\u00f5es simult\u00e2neas utilizando intensamente os threads. Vejamos como isso funciona na pr\u00e1tica.<\/p>\n

Esse MPM tenta solucionar o problema\u00a0keep alive\u00a0presente no servidor HTTPD. Um cliente HTTP sempre tenta manter a conex\u00e3o aberta e enviar mais requisi\u00e7\u00f5es pelo mesmo socket. Isso representa uma sobrecarga para TCP que gerencia a abertura e o fechamento das conex\u00f5es. Tradicionalmente, a abordagem utilizada por Apache \u00e9 manter um processo filho e seus threads aguardando por novas requisi\u00e7\u00f5es o que representa desvantagens \u00f3bvias.<\/p>\n

Para tentar solucionar essa quest\u00e3o, a MPM event realiza uma abordagem diferente utilizando um thread dedicado para manipular os sockets, que ouvem por conex\u00f5es, ao mesmo tempo que utiliza outros threads para enviar e receber dados de conex\u00f5es j\u00e1 estabelecidas.
\nPara alguns casos de uso, alguns filtros se declaram incompat\u00edveis com event e voltam a se comportar como se estivessem sendo utilizados por worker, reservando um thread por conex\u00e3o. Todos os m\u00f3dulos providos juntamente com Apache s\u00e3o compat\u00edveis com event.<\/p>\n

Observe que muitas das diretivas de worker s\u00e3o v\u00e1lidas tamb\u00e9m para event.<\/p>\n

AsyncRequestWorkerFactor\u00a0– limita o n\u00famero de conex\u00f5es concorrentes por processo. A MPM event manipula algumas conex\u00f5es de modo ass\u00edncrono. Requisi\u00e7\u00f5es que trabalham com threads s\u00e3o alocadas por um per\u00edodo de tempo curto, conforme necess\u00e1rio, e outras requisi\u00e7\u00f5es com um thread reservado por conex\u00e3o. Isso pode levar a situa\u00e7\u00e3o onde todos os workers est\u00e3o ocupados e n\u00e3o h\u00e1 threads dispon\u00edveis para manipular novas solicita\u00e7\u00f5es ass\u00edncronas de conex\u00e3o.<\/p>\n

Para mitigar esse problema, event faz duas coisas. Inicialmente, ele limita o n\u00famero de conex\u00f5es aceitas por processo, dependendo do n\u00famero de workers idle. Posteriormente, se todos os workers est\u00e3o ocupados, ele fechar\u00e1 conex\u00f5es que est\u00e3o no estado keep alive mesmo se o timeout n\u00e3o tenha sido atingido.<\/p>\n

Essa diretiva permite um ajuste mais fino (tunning) do limite das conex\u00f5es por processo. Um processo somente aceitar\u00e1 novas conex\u00f5es se o n\u00famero de conex\u00f5es correntes ( conex\u00f5es em estado closing n\u00e3o s\u00e3o contadas) for menor que:<\/p>\n

    \n
  • ThreadsPerChild\u00a0+ (AsyncRequestWorkerFactor\u00a0* n\u00famero de\u00a0idle workers)<\/li>\n<\/ul>\n

    Isso significa que o n\u00famero m\u00e1ximo de conex\u00f5es concorrentes \u00e9:<\/p>\n

      \n
    • (AsyncRequestWorkerFactor\u00a0+ 1) *\u00a0MaxRequestWorkers<\/li>\n<\/ul>\n<\/div>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n","protected":false},"excerpt":{"rendered":"

      Conceitos b\u00e1sicos Apache\u00a0\u00e9 um servidor WEB (HTTPD) portado para v\u00e1rias plataformas e ambientes. O servidor WEB Apache pode ser executado em\u00a0GNU\/Linux, Windows, Netware ou OS\/2. Para comportar essa flexibilidade de ambientes, Apache adota um projeto modular que permite ao webmaster escolher, entre um conjunto de funcionalidades, quais ser\u00e3o ativadas ou desativadas. Os m\u00f3dulos s\u00e3o implementados […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[455,1,42,51,68,271,548],"tags":[685,686,688,687],"class_list":["post-958","post","type-post","status-publish","format-standard","hentry","category-apache2","category-viazap","category-leitura-recomendada","category-linux-linuxrs","category-redes-2","category-seguranca-2","category-ubuntu-2","tag-apache-2-4","tag-modulos","tag-mpm","tag-multiprocessamento"],"_links":{"self":[{"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/posts\/958","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=958"}],"version-history":[{"count":1,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/posts\/958\/revisions"}],"predecessor-version":[{"id":959,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/posts\/958\/revisions\/959"}],"wp:attachment":[{"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=958"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=958"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=958"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}