{"id":942,"date":"2012-02-16T14:49:51","date_gmt":"2012-02-16T17:49:51","guid":{"rendered":"http:\/\/eriberto.pro.br\/blog\/?p=942"},"modified":"2012-02-20T07:31:55","modified_gmt":"2012-02-20T10:31:55","slug":"wordpress-instalacao-e-utilizacao-com-mais-desempenho-e-seguranca","status":"publish","type":"post","link":"https:\/\/eriberto.pro.br\/blog\/2012\/02\/16\/wordpress-instalacao-e-utilizacao-com-mais-desempenho-e-seguranca\/","title":{"rendered":"WordPress: instala\u00e7\u00e3o segura, desempenho e gerenciamento de mem\u00f3ria"},"content":{"rendered":"<p>Muitos, como eu, utilizam o WordPress para fazerem os seus sites e blogs. E, com certeza, o WordPress \u00e9 o sistema mais utilizado para blogs e um dos mais difundidos para sites na atualidade. O grande problema \u00e9 que a maioria dos usu\u00e1rios descompacta o WordPress dentro dos seus GNU\/Linux ou dos seus espa\u00e7os em provedores, realiza a configura\u00e7\u00e3o b\u00e1sica via web, instala um monte de plugins e&#8230; pronto. Dessa forma, poder\u00e3o ocorrer muitos problemas de desempenho e seguran\u00e7a.<\/p>\n<p>O grande objetivo deste post \u00e9 mostrar como agregar um pouco mais de seguran\u00e7a \u00e0 instala\u00e7\u00e3o e como escolher os plugins de uma forma mais cuidadosa.<\/p>\n<h2>A instala\u00e7\u00e3o do WordPress<\/h2>\n<p>Depois da cl\u00e1ssica instala\u00e7\u00e3o do tipo &#8220;<em>descompacte o .zip, chame a URL do site, configure o seu WordPress<\/em>&#8220;, algumas medidas dever\u00e3o ser adotadas. A primeira delas \u00e9 via shell (ssh, por exemplo) ou via FTP. Consiste em apagar arquivos que deem pistas sobre o seu WordPress, como vers\u00e3o etc. Ao realizar ataques, por exemplo, \u00e9 sempre bom saber o software que est\u00e1 rodando do outro lado, incluindo a sua vers\u00e3o. Um dos grandes vil\u00f5es aqui \u00e9 o arquivo readme.html do WordPress. Ele cita a vers\u00e3o do WordPress instalado. Ser\u00e1 poss\u00edvel encontrar um monte desses arquivos se voc\u00ea procurar no Google por algo como isto:<\/p>\n<pre>wordpress inurl:readme.html<\/pre>\n<p>Um exemplo de resultado, retirado da web (clique para ampliar):<\/p>\n<p style=\"text-align: center;\"><a href=\"https:\/\/eriberto.pro.br\/blog\/wp-content\/uploads\/2012\/02\/wp-web-version.jpg\"><img loading=\"lazy\" decoding=\"async\" class=\"size-medium wp-image-948 aligncenter\" title=\"wp-web-version\" src=\"https:\/\/eriberto.pro.br\/blog\/wp-content\/uploads\/2012\/02\/wp-web-version-300x160.jpg\" alt=\"\" width=\"300\" height=\"160\" srcset=\"https:\/\/eriberto.pro.br\/blog\/wp-content\/uploads\/2012\/02\/wp-web-version-300x160.jpg 300w, https:\/\/eriberto.pro.br\/blog\/wp-content\/uploads\/2012\/02\/wp-web-version.jpg 819w\" sizes=\"auto, (max-width: 300px) 100vw, 300px\" \/><\/a><\/p>\n<p>Assim sendo, apague o quanto antes os arquivos <em>license.txt<\/em> e <em>readme.html<\/em><em><\/em>, existentes na raiz do diret\u00f3rio que cont\u00e9m o WordPress. Note que esse procedimento poder\u00e1 ser necess\u00e1rio tamb\u00e9m depois de uma atualiza\u00e7\u00e3o do WP. Para tanto, utilize o comando:<\/p>\n<pre># rm license.txt readme.html<\/pre>\n<p>Mas h\u00e1 outra sa\u00edda, caso voc\u00ea deseje preservar tais arquivos. Alterar as suas permiss\u00f5es para 000 com o comando chmod.<\/p>\n<p>IMPORTANTE: depois de escrever esta parte do post, encontrei um plugin que realiza, automaticamente, as a\u00e7\u00f5es descritas acima. Ele ser\u00e1 comentado mais adiante. Trata-se do SIG.<\/p>\n<p>O pr\u00f3ximo passo ser\u00e1 alterar o n\u00edvel de permiss\u00e3o de acesso ao arquivo <em>wp-config.php<\/em>, que cont\u00e9m a senha de acesso ao banco<em><\/em> de dados. Este passo s\u00f3 dever\u00e1 ser realizado depois da configura\u00e7\u00e3o inicial do WordPress, ou seja, j\u00e1 dever\u00e1 ter ocorrido a conex\u00e3o entre o WP e o banco de dados. Para tanto, utilize o comando a seguir:<\/p>\n<pre># chmod 400 wp-config.php<\/pre>\n<p>Dependendo de como o servidor de p\u00e1ginas esteja configurado, poderemos alterar mais um n\u00edvel de permissionamento. Um exemplo disso \u00e9 o Apache2 no Debian, que roda sob o usu\u00e1rio www-data. Ent\u00e3o, neste caso, para maior seguran\u00e7a, devermos deixar arquivos com 640 (exceto o <em>wp-config.php<\/em>) e os diret\u00f3rios com 750. Ainda, todos os arquivos e diret\u00f3rios, inclusive o que cont\u00e9m o WordPress, dever\u00e3o pertencer ao usu\u00e1rio www-data. Para isso, considerando que o site WordPress esteja em \/var\/www\/teste\/, deveremos executar:<\/p>\n<pre># find \/var\/www\/teste -type f -perm 644 -exec chmod 640 {} \\;\r\n# find \/var\/www\/teste -type d -perm 755 -exec chmod 750 {} \\;\r\n# chown -R www-data.www-data \/var\/www\/teste<\/pre>\n<p>O \u00faltimo item deste t\u00f3pico, mas n\u00e3o menos importante,\u00e9 sobre a conta de administrador. Essa conta, por default, \u00e9 criada com o nome de usu\u00e1rio admin. Ent\u00e3o, os rob\u00f4s da Internet que buscam descobrir senhas utilizam sempre admin como usu\u00e1rio para tentarem entrar no blog. Por este e muitos outros motivos, \u00e9 fundamental que voc\u00ea crie um usu\u00e1rio com outro nome para ser administrador e exclua o admin.<\/p>\n<p>Esta \u00e9 a configura\u00e7\u00e3o b\u00e1sica de seguran\u00e7a do WordPress. Os pr\u00f3ximos t\u00f3picos tentar\u00e3o descobrir &#8220;brechas&#8221; ou problemas.<\/p>\n<h2>De olho no log<\/h2>\n<p>A partir de agora deveremos ter o cuidado de verificar se aparecem erros no log <em>\/var\/log\/apache2\/error.log<\/em>. \u00c9 MUITO IMPORTANTE testar o WordPress com o tema padr\u00e3o e sem plugins. Teste com uma p\u00e1gina ou com um post e um coment\u00e1rio, dependendo do seu caso. Depois, configure o WordPress, utilizando o painel de controle, de acordo com o seu gosto. Verifique o log novamente. Somente depois disso, instale temas e plugins. Mas n\u00e3o esque\u00e7a de testar um a um.<\/p>\n<h2>Atualize sempre!<\/h2>\n<p>Ao ser informado sobre atualiza\u00e7\u00f5es no core do WordPress, em plugins ou temas, n\u00e3o hesite! Sistemas atualizados s\u00e3o chave primordial para manter a seguran\u00e7a do seu site. Atualizar ajuda a evitar invas\u00f5es, defacements etc. H\u00e1 plugins que avisam por e-mail sempre que uma atualiza\u00e7\u00e3o \u00e9 lan\u00e7ada. Particularmente, gosto do WP Updates Notifier.<\/p>\n<p>Mas h\u00e1 uma regra b\u00e1sica para atualiza\u00e7\u00f5es sem impacto: evite alterar o c\u00f3digo-fonte do WordPress. Muitos sites ensinam dicas e truques que ir\u00e3o requerer altera\u00e7\u00e3o de c\u00f3digo. Isso n\u00e3o \u00e9 bom, pois qualquer atualiza\u00e7\u00e3o ir\u00e1 matar as suas altera\u00e7\u00f5es. Prefira utilizar plugins que executem tarefas espec\u00edficas em vez de alterar c\u00f3digo para obter benef\u00edcios.<\/p>\n<h2>Cuidados com temas e plugins<\/h2>\n<p>A maioria dos usu\u00e1rios de WordPress adora instalar temas e plugins indiscriminadamente. Realmente \u00e9 prazeroso ter um monte de recursos. No entanto, temas n\u00e3o testados e plugins diversos podem trazer alguns problemas, como:<\/p>\n<ul>\n<li>Bugs. Um tema ou um plugin pode n\u00e3o funcionar corretamente. Com isso n\u00e3o teremos os resultados desejados, ou teremos resultados indesejados, ou poderemos ter ocorr\u00eancias de dif\u00edcil observa\u00e7\u00e3o mas que nos levar\u00e3o de simples telas brancas a desastres, como a perda de dados.<\/li>\n<li>Problemas de seguran\u00e7a. Isso poder\u00e1 ocorrer principalmente em plugins que interagem com usu\u00e1rios. Assim, antes de instalar um plugin desse tipo, procure saber sobre o mesmo na Internet.<\/li>\n<li>Queda do servi\u00e7o durante atualiza\u00e7\u00f5es do WP. Plugins e temas poder\u00e3o n\u00e3o estar preparados para novas vers\u00f5es do WordPress por ocasi\u00e3o de atualiza\u00e7\u00f5es.<\/li>\n<li>Esgotamento de mem\u00f3ria. Quanto mais plugins voc\u00ea tiver, mais consumo de mem\u00f3ria voc\u00ea ter\u00e1. E muitos provedores n\u00e3o toleram isso. Aten\u00e7\u00e3o tamb\u00e9m para plugins que consomem mem\u00f3ria descontroladamente.<\/li>\n<\/ul>\n<p>Como conselho final neste t\u00f3pico, tenha o M\u00cdNIMO de plugins instalados sempre. Quanto menos, melhor! Mas, para isso, voc\u00ea ter\u00e1 que vencer a sua vontade de ter milh\u00f5es de plugins instalados. Ent\u00e3o, preocupe-se se estiver utilizando mais de 10 plugins. Al\u00e9m disso, verifique o consumo de mem\u00f3ria, erros etc. E cuidado com os sites que dizem: 30 maravilhosos plugins para isso ou aquilo. A maioria deles \u00e9 maravilhosa mesmo. No entanto, os autores desses sites, raramente, testam os plugins que usam ou aconselham e&#8230; Espalham o caos.<\/p>\n<h2>Fechando o acesso aos diret\u00f3rios de plugins<\/h2>\n<p>Alguns plugins permitem o acesso aos seu diret\u00f3rios (que podem conter dados valiosos armazenados). Um deles, pelo menos at\u00e9 a vers\u00e3o atual, \u00e9 o Lightbox Gallery, muito conhecido e utilizado. Para saber sobre o que estou falando, procure no Google por:<\/p>\n<pre>inurl:plugins lightbox-gallery<\/pre>\n<p>Assim, \u00e9 uma boa ideia bloquear o acesso direto ao diret\u00f3rio de cada plugin instalado. H\u00e1 v\u00e1rias formas de fazer isto. Vou citar duas:<\/p>\n<ul>\n<li>Se voc\u00ea tiver acesso \u00e0s configura\u00e7\u00f5es do servidor de p\u00e1ginas e se este for um Apache2, edite o arquivo de configura\u00e7\u00e3o do site (possivelmente em \/etc\/apache2\/sites-available\/) e adicione:<\/li>\n<\/ul>\n<pre>&lt;Directory \/var\/www\/site\/wp-content\/plugins&gt;\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Options -Indexes\r\n&lt;\/Directory&gt;<\/pre>\n<p>Observe que voc\u00ea dever\u00e1 alterar, no c\u00f3digo acima, a primeira linha, de forma que o path referente ao diret\u00f3rio de plugins fique correto.<\/p>\n<ul>\n<li>Se voc\u00ea n\u00e3o tiver acesso \u00e0s configura\u00e7\u00f5es do servidor de p\u00e1ginas, poder\u00e1 criar um index.php vazio dentro dos diret\u00f3rios de plugins que n\u00e3o contenham qualquer index (index.php, index.html etc). Realmente esta n\u00e3o \u00e9 a solu\u00e7\u00e3o mais profissional. No entanto, ela cai bem neste caso, pois ser\u00e1 poss\u00edvel resolver o problema em provedores de acesso e tamb\u00e9m criar esse tipo de arquivo via script, se o servidor ou provedor permitir o agendamento de tarefas.<\/li>\n<\/ul>\n<p>IMPORTANTE: o mesmo plugin que citei anteriormente, aquele que encontrei depois de escrever as primeiras partes deste post, tamb\u00e9m cuida dos diret\u00f3rios sem index. Ele ser\u00e1 comentado mais adiante. Trata-se do SIG.<\/p>\n<h2>Plugins essenciais para seguran\u00e7a<\/h2>\n<p>Alguns plugins s\u00e3o muito interessantes para a seguran\u00e7a. Na verdade, eles s\u00e3o essenciais e vale a pena t\u00ea-los. \u00c9 importante ressaltar que todos foram testados de forma b\u00e1sica, inclusive no que tange a consumo de mem\u00f3ria.<\/p>\n<h3>WordPress Firewall 2<\/h3>\n<p>Este plugin detecta ataques diversos, bloqueando-os. Utiliza eur\u00edsticas e pode avisar, via e-mail, sobre atividades irregulares ocorridas. Simples e r\u00e1pido de configurar.<\/p>\n<h3>WP Sanitize<strong><br \/>\n<\/strong><\/h3>\n<p>O WP Sanitize realiza algumas a\u00e7\u00f5es de seguran\u00e7a muito importantes. Dentre elas, remove a vers\u00e3o do WordPress das p\u00e1ginas apresentadas na Internet. Ele tamb\u00e9m possui um recurso muito \u00fatil, que \u00e9 a limpeza di\u00e1ria autom\u00e1tica do banco de dados, removendo os overhead (lixo deixado no banco).<\/p>\n<h3>WP Updates Notifier<\/h3>\n<p>Avisa, via e-mail, sobre a atualiza\u00e7\u00e3o de elementos no WordPress. S\u00e3o eles: o core, plugins e temas. Mas n\u00e3o abuse, pois essas verifica\u00e7\u00f5es consomem mem\u00f3ria e link, e provedores n\u00e3o gostam disso. Sugiro uma verifica\u00e7\u00e3o por dia.<\/p>\n<h3>Silence is Golden Guard plugin (SIG)<\/h3>\n<p>O plugin \u00e9 capaz de fazer verifica\u00e7\u00f5es di\u00e1rias no WordPress, atuando sobre problemas encontrados. Alguns j\u00e1 foram descritos neste post e foi gratificante encontrar um plugins que automatizasse as a\u00e7\u00f5es. Algumas delas: cria arquivos index.php em diret\u00f3rios de plugins e outros, apaga arquivos readme.txt etc. <span style=\"color: #ff0000;\">NO ENTANTO<\/span>, este plugin ao ser ativado, consome 5 MB de RAM constantemente (um valor absurdo para WordPress). Esse detalhe foi visto com o aux\u00edlio do plugin PHP memory indicator. Assim, creio que seja uma boa ideia deix\u00e1-lo desativado. De vez em quando, ative-o, clique em Scan Now (dispon\u00edvel na p\u00e1gina de configura\u00e7\u00e3o do plugin) e desative-o. Recomendo que fa\u00e7a isso sempre que houver qualquer instala\u00e7\u00e3o ou upgrade de core, tema ou plugin. Ent\u00e3o, o seu WordPress estar\u00e1 protegido e n\u00e3o haver\u00e1 consumo de mem\u00f3ria desnecessariamente.<\/p>\n<h3>WordPress File Monitor Plus<\/h3>\n<p>Este plugin realiza o famoso check de integridade do sistema, avisando por e-mail caso algum arquivo tenha sido criado, apagado ou alterado. \u00c9 bem configur\u00e1vel e essencial para denunciar casos de invas\u00e3o ou prepara\u00e7\u00e3o para a invas\u00e3o. Use isto!!!<\/p>\n<h3>BackUpWordPress<\/h3>\n<p>Backup sempre \u00e9 necess\u00e1rio. Este plugin \u00e9 simples e eficiente. No entanto, ocupa cerca de 1 MB de mem\u00f3ria quando ativado. Assim, caso voc\u00ea n\u00e3o tenha outro meio de realizar backup, ative-o. No entanto, caso possa, prefira backup via provedor. Ou ainda, caso o seu provedor lhe d\u00ea acesso via shell, como \u00e9 o meu caso, utilize scripts e tarefas agendadas. Ainda, voc\u00ea ter\u00e1 problemas em provedores de hospedagem compartilhada, caso o seu conte\u00fado WP seja muito grade. Isso porque durante o backup haver\u00e1 alto consumo de mem\u00f3ria e o processo ser\u00e1 encerrado prematuramente. Com isso, dependendo do caso, voc\u00ea nunca ter\u00e1 backup.<\/p>\n<p>Apesar de ocupar 1 MB de RAM, o plugin \u00e9 o mais simples e eficiente que testei. Cheguei a us\u00e1-lo quando hospedava em outro provedor que n\u00e3o me concedia shell. Para se ter uma ideia, o plugin Backup Scheduler, quando ativado, s\u00f3 em stand by, j\u00e1 ocupa mais de 5 MB de RAM.<\/p>\n<h2>Agora, veja os logs&#8230;<\/h2>\n<p>Se voc\u00ea tiver acesso aos logs do servidor, olh\u00e1-los ser\u00e1 o pr\u00f3ximo passo. O que nos interessa \u00e9 o log error.log do Apache. Normalmente fica em \/var\/log\/apache2\/error.log. L\u00e1 ser\u00e1 poss\u00edvel encontrar algumas ocorr\u00eancias irregulares, como esta:<\/p>\n<pre>[Thu Feb 16 14:27:23 2012] [error] [client 200.x.x.1] File does not exist: \/var\/www\/wp2\/wp-content\/plugins\/silence-is-golden-guard\/images\/tom.png, referer: http:\/\/www.rede.com.br\/wp2\/wp-admin\/options-general.php?page=sig-guard.php<\/pre>\n<p>Neste caso, \u00e9 n\u00edtido que est\u00e1 faltando o arquivo \/var\/www\/wp2\/wp-content\/plugins\/silence-is-golden-guard\/images\/tom.png. Geralmente os problemas apresentados ser\u00e3o relativos \u00e0 falta de arquivos. Mas isso \u00e9 importante? Sim! Muito! Porque haver\u00e1 consumo de mais tempo e mem\u00f3ria procurando algo que n\u00e3o existe e, logo depois, escrevendo em log. Os logs tamb\u00e9m ficar\u00e3o recheados e ocupando espa\u00e7o. Ent\u00e3o, deveremos fazer os seguinte:<\/p>\n<ul>\n<li>Criar os arquivos faltosos, deixando vazio o seu conte\u00fado. Isso poder\u00e1 ser feito com o comando touch. Exemplo:<\/li>\n<\/ul>\n<pre># touch \/var\/www\/wp2\/wp-content\/plugins\/silence-is-golden-guard\/images\/tom.png<\/pre>\n<ul>\n<li>Avisar ao autor sobre o problema para que ele possa corrigi-lo. Isso poder\u00e1 ser feito na p\u00e1gina espec\u00edfica do plugin, dentro do site <a href=\"http:\/\/wordpress.org\/extend\/plugins\">http:\/\/wordpress.org\/extend\/plugins<\/a>.<\/li>\n<\/ul>\n<h2>Tratando a mem\u00f3ria<\/h2>\n<p>A partir de agora falaremos um pouco sobre mem\u00f3ria.<\/p>\n<p>O WordPress costuma ser uma dor de cabe\u00e7a para os provedores de conte\u00fado, uma vez que a maioria dos administradores de blogs e sites costuma instalar milh\u00f5es de plugins sem saber o que est\u00e1 fazendo. Ent\u00e3o, os WordPress da vida v\u00e3o virando monstros comedores de RAM. Na maioria das vezes, os provedores optam por utilizar ferramentas que matam os processos, principalmente os baseados em PHP, que estejam consumindo muita mem\u00f3ria. O resultado disso, geralmente, ser\u00e1 uma mensagem &#8220;500 Internal Server Error&#8221; na tela de quem acessa o site. Isso ocorre, especialmente, em provedores com hospedagem compartilhada, onde v\u00e1rios site s\u00e3o abrigados pela mesma m\u00e1quina e usam o mesmo processador e a mesma mem\u00f3ria.<\/p>\n<h3>O ajuste da mem\u00f3ria<\/h3>\n<p>Regras de ouro, caso esteja utilizando um espa\u00e7o comprado em um provedor:<\/p>\n<ul>\n<li>Nunca abuse de plugins.<\/li>\n<li>Otimize ao m\u00e1ximo o seu WordPress.<\/li>\n<li>Fa\u00e7a medi\u00e7\u00e3o de uso de mem\u00f3ria com plugin espec\u00edfico para isso.<\/li>\n<\/ul>\n<p>Al\u00e9m disso, o WordPress vem configurado para utilizar somente 32 MB de RAM em caso de uso simples ou 64 MB para multisites, que \u00e9 a situa\u00e7\u00e3o referente a disponibilizar v\u00e1rios sites e blogs utilizando apenas um motor WordPress. No entanto um WordPress com um tema comum e alguns plugins, em standby, j\u00e1 consome uns 35 MB ou mais. O tema escolhido tamb\u00e9m interfere nisso. E por incr\u00edvel que pare\u00e7a, plugins instalados, mesmo desativados, tamb\u00e9m consomem mem\u00f3ria. Ent\u00e3o, ser\u00e1 necess\u00e1rio ampliar esse limite de 32 MB ou voc\u00ea enfrentar\u00e1 constantes erros 500. Mas o limite de mem\u00f3ria a ser utilizado pelo WordPress n\u00e3o poder\u00e1 ser maior que o limite estabelecido pelo PHP para todas as aplica\u00e7\u00f5es gerenciadas por ele.<\/p>\n<p>A primeira a\u00e7\u00e3o ser\u00e1 instalar um plugin de visualiza\u00e7\u00e3o de mem\u00f3ria. Lembre-se de desativ\u00e1-lo depois do uso! Ent\u00e3o, sugiro o &#8220;PHP memory indicator&#8221;. Ele mostra dados no rodap\u00e9 da p\u00e1gina. Veja a figura a seguir (clique para ampliar):<\/p>\n<p><a href=\"https:\/\/eriberto.pro.br\/blog\/wp-content\/uploads\/2012\/02\/wp_memory.jpg\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-medium wp-image-1002\" title=\"wp_memory\" src=\"https:\/\/eriberto.pro.br\/blog\/wp-content\/uploads\/2012\/02\/wp_memory-256x300.jpg\" alt=\"\" width=\"256\" height=\"300\" srcset=\"https:\/\/eriberto.pro.br\/blog\/wp-content\/uploads\/2012\/02\/wp_memory-256x300.jpg 256w, https:\/\/eriberto.pro.br\/blog\/wp-content\/uploads\/2012\/02\/wp_memory.jpg 509w\" sizes=\"auto, (max-width: 256px) 100vw, 256px\" \/><\/a><\/p>\n<p>O primeiro valor exibido \u00e9 a quantidade de mem\u00f3ria utilizada pelo WordPress (40.74 MB), incluindo o tema e plugins. O segundo valor \u00e9 a quantidade m\u00e1xima de mem\u00f3ria com utiliza\u00e7\u00e3o permitida pelas configura\u00e7\u00f5es do PHP (90 MB). O limite de mem\u00f3ria imposto pelo WordPress n\u00e3o \u00e9 mostrado.<\/p>\n<p>No caso anterior, sabendo que o valor limite default do WordPress para sites e blogs fora do sistema multisites \u00e9 32 MB, faltar\u00e1 mem\u00f3ria. Com isso, teremos um festival de erros 500, pois os acessos de usu\u00e1rios ir\u00e3o gerar um uso de mem\u00f3ria que ser\u00e1 rejeitado pelo sistema. Para evitar isso, poderemos alterar as configura\u00e7\u00f5es do WordPress. Procure utilizar o valor m\u00e1ximo permitido pelo PHP, reduzido em 10%. Ou seja: 90 &#8211; 10% = 81 MB.<\/p>\n<p>Para alterar a quantidade de mem\u00f3ria utilizada pelo WordPress, aumentando de 32 para 81 MB, edite o arquivo wp-config.php (na raiz do WordPress) e insira no in\u00edcio, logo depois de <em>&lt;?php<\/em>:<\/p>\n<pre>define('WP_MEMORY_LIMIT', '81M');<\/pre>\n<p>Caso voc\u00ea precise de um maior controle sobre o que est\u00e1 ocorrendo na mem\u00f3ria e informa\u00e7\u00f5es detalhadas sobre o sistema, utilize o plugin TPC! Memory Usage. Ele \u00e9 um pouco dif\u00edcil de encontrar. Ent\u00e3o, clique <a href=\"http:\/\/wordpress.org\/extend\/plugins\/tpc-memory-usage\">aqui<\/a>. Mas lembre-se: depois de utilizar, desative-o! A seguir um exemplo de tela de informa\u00e7\u00f5es do plugin (clique para ampliar):<\/p>\n<p><a href=\"https:\/\/eriberto.pro.br\/blog\/wp-content\/uploads\/2012\/02\/tpc_memory1.jpg\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-medium wp-image-1010\" title=\"tpc_memory\" src=\"https:\/\/eriberto.pro.br\/blog\/wp-content\/uploads\/2012\/02\/tpc_memory1-300x221.jpg\" alt=\"\" width=\"300\" height=\"221\" srcset=\"https:\/\/eriberto.pro.br\/blog\/wp-content\/uploads\/2012\/02\/tpc_memory1-300x221.jpg 300w, https:\/\/eriberto.pro.br\/blog\/wp-content\/uploads\/2012\/02\/tpc_memory1.jpg 587w\" sizes=\"auto, (max-width: 300px) 100vw, 300px\" \/><\/a><\/p>\n<h3>Mito: plugin para medir uso de mem\u00f3ria lhe dir\u00e1 tudo!<\/h3>\n<p>Muitos e muitos sites e blogs, na verdade todos os que eu vi, dizem que plugins como o TCP! Memory Usage mostram toda a mem\u00f3ria que o WordPress est\u00e1 usando. Diversos sites ensinam: &#8220;olhe a quantidade de mem\u00f3ria utilizada pelo WordPress no radap\u00e9, antes e depois da instala\u00e7\u00e3o do plugin. A diferen\u00e7a entre os dois ser\u00e1 a quantidade de mem\u00f3ria gasta pelo plugin&#8221;. <span style=\"color: #ff0000;\"><strong>ERRADO!!!!!!<\/strong><\/span><\/p>\n<p>Qualquer processo, quando ativo, consome muito mais mem\u00f3ria do que quando est\u00e1 em standby. Ent\u00e3o, um plugin como o BackUpWordPress, por exemplo, ir\u00e1 consumir muito mais mem\u00f3ria no momento em que estiver realizando o backup. Al\u00e9m disso, h\u00e1 diversas vari\u00e1veis que interferem de forma diferente no sistema a cada instante. Ent\u00e3o, se voc\u00ea instalar, por exemplo, o PHP memory indicator e executar v\u00e1rios refreshes no browser enquanto olha o rodap\u00e9, notar\u00e1 que o consumo de mem\u00f3ria variar\u00e1 um pouco. Porque \u00e9 assim que um sistema operacional funciona! Simples!<\/p>\n<p>Vamos a um exemplo. No rodap\u00e9 de um WordPress, podemos ver:<\/p>\n<pre id=\"footer-left\">Obrigado por criar com o WordPress. | Load 40.72 of 90M<\/pre>\n<p>Agora, vamos instalar o plugin BackUpWordPress. Depois da instala\u00e7\u00e3o, o sistema mostra:<\/p>\n<pre id=\"footer-left\">Obrigado por criar com o WordPress. | Load 41.56 of 90M<\/pre>\n<p>Vamos desinstalar e ver como fica. Resultado:<\/p>\n<pre id=\"footer-left\">Obrigado por criar com o WordPress. | Load 40.69 of 90M<\/pre>\n<p>Observe que houve uma pequena varia\u00e7\u00e3o, ou seja, o valor final n\u00e3o foi 40.72 e sim 40.69. Isso \u00e9 o esperado em um sistema operacional. Com isso, a teoria mostrada na maioria dos sites est\u00e1 um pouco fora da realidade, apesar de ser ineg\u00e1vel que voc\u00ea ter\u00e1 uma excelente ideia do consumo de mem\u00f3ria COM O PLUGIN EM STANDBY. N\u00e3o \u00e9 exato. \u00c9 aproximado. Mas muito pr\u00f3ximo do real.<\/p>\n<p>Agora vamos fazer uma prova de fogo. Passei a monitorar a mem\u00f3ria com um watch. Depois de v\u00e1rios refreshes em cima do browser que mostra o WordPress, obtive:<\/p>\n<pre># watch -n1 free -m\r\n\r\nEvery 1,0s: free -m\r\n\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 total\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 used\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 free\u00a0\u00a0\u00a0\u00a0 shared\u00a0\u00a0\u00a0 buffers\u00a0\u00a0\u00a0\u00a0 cached\r\nMem:\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 3516\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 792\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 2724\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 99\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 240\r\n<strong>-\/+ buffers\/cache:\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 452\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 3064<\/strong>\r\nSwap:\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 0<\/pre>\n<p>Em outras palavras, o sistema est\u00e1 gastando 452 MB de RAM para se manter neste momento. Agora iniciarei, manualmente, uma opera\u00e7\u00e3o de backup via plugin. Veja o resultado, durante todo o per\u00edodo do backup:<\/p>\n<pre>-\/+ buffers\/cache:\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 <strong>483<\/strong>\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 3033<\/pre>\n<p>A opera\u00e7\u00e3o foi repetida e o mesmo resultado foi obtido novamente. Isso quer dizer que, durante o backup, 31 MB de RAM s\u00e3o consumidos (483 MB &#8211; 452 MB). \u00c9 l\u00f3gico que n\u00e3o foi o plugin quem gastou sozinho esses 31 MB. Isso porque h\u00e1 chamadas de sistema envolvidas, que tamb\u00e9m consomem mem\u00f3ria. Mas consideremos que o BackUpWordPress tenha utilizado, pelo menos, 30% desse total (n\u00famero m\u00e1gico que saiu da minha cabe\u00e7a). Ent\u00e3o, podemos arbitrar que o plugin consumiu cerca de 9 MB. Resumo: o plugin ocupa cerca de 850 KB em standby e, estimativamente, 9 MB ou mais em funcionamento. Assim sendo, fique de olho nos seus plugins e temas (tamb\u00e9m ocupam mem\u00f3ria).<\/p>\n<p>\u00c9 importante ressaltar que, al\u00e9m de consumo de mem\u00f3ria, \u00e9 durante o seu funcionamento que plugins podem apresentar falhas de seguran\u00e7a. Uma aten\u00e7\u00e3o especial deve ser dada aos plugins que interagem com o usu\u00e1rio.<\/p>\n<h2>Conclus\u00e3o<\/h2>\n<p>A correta instala\u00e7\u00e3o do WordPress \u00e9 muito importante para o seu funcionamento. Seguran\u00e7a tamb\u00e9m \u00e9 primordial. Assim, v\u00e1rios detalhes dever\u00e3o ser observados. Provedores como o <a href=\"http:\/\/dreamhost.com\/\">DreamHost<\/a> ser\u00e3o o c\u00e9u ou o inferno, dependendo de como voc\u00ea hospede o seu site. Se fizer errado ou de qualquer jeito, com certeza, voc\u00ea ser\u00e1 presenteado com um festival de erros 500.<\/p>\n<p>Uma dica \u00e9 testar em um servidor local todo o seu ambiente, antes de fazer upload para o provedor. Observe mensagens de erro nos logs, consumo de mem\u00f3ria com aux\u00edlio do comando free e plugin espec\u00edfico etc. Assim, voc\u00ea escolher\u00e1 os melhores plugins e temas. E lembre-se do conselho final: n\u00e3o abuse dos plugins!!! Eles poder\u00e3o esgotar a mem\u00f3ria e, talvez, abrir brechas de seguran\u00e7a.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Muitos, como eu, utilizam o WordPress para fazerem os seus sites e blogs. E, com certeza, o WordPress \u00e9 o sistema mais utilizado para blogs e um dos mais difundidos para sites na atualidade. O grande problema \u00e9 que a maioria dos usu\u00e1rios descompacta o WordPress dentro dos seus GNU\/Linux ou dos seus espa\u00e7os em&hellip;&nbsp;<a href=\"https:\/\/eriberto.pro.br\/blog\/2012\/02\/16\/wordpress-instalacao-e-utilizacao-com-mais-desempenho-e-seguranca\/\" rel=\"bookmark\">Continue a ler &raquo;<span class=\"screen-reader-text\">WordPress: instala\u00e7\u00e3o segura, desempenho e gerenciamento de mem\u00f3ria<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"neve_meta_sidebar":"","neve_meta_container":"","neve_meta_enable_content_width":"","neve_meta_content_width":0,"neve_meta_title_alignment":"","neve_meta_author_avatar":"","neve_post_elements_order":"","neve_meta_disable_header":"","neve_meta_disable_footer":"","neve_meta_disable_title":"","footnotes":""},"categories":[24,3,4,5],"tags":[438,440,405,432,406,624,212,423,435,434,439,625,211,200,621,123,422,403,146,437,622,424,623,402,425,436,404,433],"class_list":["post-942","post","type-post","status-publish","format-standard","hentry","category-internet","category-linux","category-rede","category-seguranca","tag-438","tag-acabar-com-erro-500","tag-cms","tag-consumo-de-memoria","tag-content-management-system","tag-debian","tag-defacement","tag-desempenho","tag-hospedagem","tag-hospedagem-compartilhada","tag-internal-server-error","tag-internet","tag-intrusao","tag-invasao","tag-linux","tag-memoria","tag-performance","tag-plugins","tag-provedor","tag-provedor-de-hospedagem","tag-rede","tag-security","tag-seguranca","tag-sites","tag-web","tag-web-hosting","tag-wordpress","tag-wp"],"_links":{"self":[{"href":"https:\/\/eriberto.pro.br\/blog\/wp-json\/wp\/v2\/posts\/942","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/eriberto.pro.br\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/eriberto.pro.br\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/eriberto.pro.br\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/eriberto.pro.br\/blog\/wp-json\/wp\/v2\/comments?post=942"}],"version-history":[{"count":0,"href":"https:\/\/eriberto.pro.br\/blog\/wp-json\/wp\/v2\/posts\/942\/revisions"}],"wp:attachment":[{"href":"https:\/\/eriberto.pro.br\/blog\/wp-json\/wp\/v2\/media?parent=942"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/eriberto.pro.br\/blog\/wp-json\/wp\/v2\/categories?post=942"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/eriberto.pro.br\/blog\/wp-json\/wp\/v2\/tags?post=942"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}