Axuste de Linux para mellorar o rendemento de PostgreSQL. Ilya Kosmodemyansky

Transcrición do informe de 2015 de Ilya Kosmodemyansky "Axuste de Linux para mellorar o rendemento de PostgreSQL"

Descargo de responsabilidade: observo que este informe ten data de novembro de 2015: pasaron máis de 4 anos e pasou moito tempo. A versión 9.4 que se comenta no informe xa non é compatible. Durante os últimos 4 anos, lanzáronse 5 novas versións de PostgreSQL e 15 versións do núcleo de Linux. Se reescribes estas pasaxes, acabarás cun informe diferente. Pero aquí consideramos a axuste fundamental de Linux para PostgreSQL, que aínda é relevante hoxe en día.

Chámome Ilya Kosmodemyansky. Traballo en PostgreSQL-Consulting. E agora falarei un pouco de que facer con Linux en relación coas bases de datos en xeral e PostgreSQL en particular, porque os principios son bastante parecidos.

De que falaremos? Se te comunicas con PostgreSQL, ata certo punto necesitas ser administrador de UNIX. Qué significa? Se comparamos Oracle e PostgreSQL, entón en Oracle debes ser un 80% administrador de bases de datos de DBA e un 20% administrador de Linux.

Con PostgreSQL é un pouco máis complicado. Con PostgreSQL necesitas ter unha comprensión moito mellor de como funciona Linux. E ao mesmo tempo, corre un pouco despois da locomotora, porque ultimamente todo se actualizou bastante ben. E lánzanse novos núcleos, aparecen novas funcionalidades, mellora o rendemento, etc.

Por que falamos de Linux? En absoluto porque esteamos na conferencia de Linux Peter, senón porque en condicións modernas un dos sistemas operativos máis xustificados para usar bases de datos en xeral e PostgreSQL en particular é Linux. Porque FreeBSD, por desgraza, está a desenvolverse nunha dirección moi estraña. E haberá problemas tanto de rendemento como de moitas outras cousas. O rendemento de PostgreSQL en Windows é xeralmente un problema serio separado, baseado no feito de que Windows non ten a mesma memoria compartida que UNIX, mentres que PostgreSQL está todo ligado a isto, porque é un sistema multiproceso.

E creo que todo o mundo está menos interesado en exóticos como Solaris, así que imos.

Unha distribución de Linux moderna ten máis de 1 opcións syctl, dependendo de como constrúe o núcleo. Ao mesmo tempo, se observamos as diferentes noces, podemos axustar algo de moitas maneiras. Hai parámetros do sistema de ficheiros sobre como montalos. Se tes dúbidas sobre como inicialo: que activar na BIOS, como configurar o hardware, etc.

Este é un volume moi grande que se pode discutir durante varios días, e non nun breve informe, pero agora centrareime en cousas importantes, como evitar eses rastrillos que están garantidos para evitar que uses ben a túa base de datos en Linux se non os corrixa. E, ao mesmo tempo, un punto importante é que moitos parámetros predeterminados non están incluídos na configuración correcta para a base de datos. É dicir, por defecto funcionará mal ou non funcionará nada.

Que obxectivos de axuste tradicionais hai en Linux? Creo que, dado que todos vostedes están lidando coa administración de Linux, non hai ningunha necesidade particular de explicar cales son os obxectivos.

Podes sintonizar:

• CPUs.
• Memoria.
• Almacenamento.
• Outra. Disto falaremos ao final para unha merenda. Incluso, por exemplo, parámetros como a política de aforro enerxético poden afectar o rendemento dun xeito moi imprevisible e non do máis agradable.

Cales son as características específicas de PostgreSQL e da base de datos en xeral? O problema é que non podes modificar ningunha porca individual e ver que o noso rendemento mellorou significativamente.

Si, existen tales gadgets, pero unha base de datos é algo complexo. Interactúa con todos os recursos que ten o servidor e prefire interactuar ao máximo. Se miras as recomendacións actuais de Oracle sobre como usar un sistema operativo anfitrión, será como a broma sobre ese cosmonauta mongol: alimenta ao can e non toca nada. Dámoslle á base de datos todos os recursos, a propia base de datos resolverá todo.

En principio, ata certo punto a situación é exactamente a mesma con PostgreSQL. A diferenza é que a base de datos aínda non é capaz de tomar todos os recursos por si mesma, é dicir, nalgún lugar a nivel de Linux debes resolvelo todo ti mesmo.

A idea principal non é seleccionar un só obxectivo e comezar a axustalo, por exemplo, a memoria, a CPU ou algo así, senón analizar a carga de traballo e tratar de mellorar o máximo posible o rendemento para que a carga que crean os bos programadores o crearon. para nós, incluídos os nosos usuarios.

Aquí tedes unha imaxe para explicar o que é. Hai un búfer do sistema operativo Linux e hai memoria compartida e hai búfers compartidos PostgreSQL. PostgreSQL, a diferenza de Oracle, funciona directamente só a través do búfer do núcleo, é dicir, para que unha páxina do disco entre na súa memoria compartida, debe pasar polo búfer do núcleo e volver, exactamente a mesma situación.

Os discos viven baixo este sistema. Debuxen isto como discos. De feito, pode haber un controlador RAID, etc.

E esta entrada-saída ocorre dun xeito ou doutro por este asunto.

PostgreSQL é unha base de datos clásica. Dentro hai unha páxina. E toda a entrada e saída ocorre usando páxinas. Estamos levantando bloques na memoria con páxinas. E se non pasou nada, só os lemos, logo desaparecen pouco a pouco desta caché, dos búfers compartidos e acaban de novo no disco.

Se substituímos algo nalgún lugar, a páxina enteira está marcada como sucia. Marqueinos aquí en azul. E isto significa que esta páxina debe estar sincronizada co almacenamento en bloque. É dicir, cando a ensuciamos, fixemos unha entrada en WAL. E nalgún momento marabilloso, chegou un fenómeno chamado checkpoint. E neste rexistro constaba a información de que chegara. E isto significa que todas as páxinas sucias que estaban aquí nese momento nestes búfers compartidos sincronizáronse co disco de almacenamento mediante fsync a través do búfer do núcleo.

Por que se fai isto? Se perdíamos voltaxe, entón non obtivemos a situación de que se perderan todos os datos. A memoria persistente, da que todos nos falaron, está ata agora na teoría de bases de datos: este é un futuro brillante, polo que, por suposto, nos esforzamos e gústanos, pero por agora viven en menos de 20 anos. E, por suposto, hai que vixiar todo isto.

E a tarefa de maximizar o rendemento é perfeccionar todas estas etapas para que todo se mueva rapidamente cara atrás e cara atrás. A memoria compartida é basicamente unha caché de páxina. En PostgreSQL enviamos unha consulta de selección ou algo así, recuperou estes datos do disco. Remataron en buffers compartidos. En consecuencia, para que isto funcione mellor, debe haber moita memoria.

Para que todo isto funcione ben e rapidamente, cómpre configurar correctamente o sistema operativo en todas as fases. E elixe hardware equilibrado, porque se tes un desequilibrio nalgún lugar, podes facer moita memoria, pero non se atenderá á velocidade suficiente.

E imos pasar por cada un destes puntos.

Para facer que estas páxinas viaxan máis rápido, debes conseguir o seguinte:

• En primeiro lugar, cómpre traballar de forma máis eficiente coa memoria.
• En segundo lugar, esta transición cando as páxinas da memoria van ao disco debería ser máis eficiente.
• E en terceiro lugar, debe haber bos discos.

Se tes 512 GB de RAM no servidor e todo acaba nun disco duro SATA sen caché, entón todo o servidor de base de datos convértese non só nunha cabaza, senón nunha cabaza cunha interface SATA. Vai atopar directamente con el. E nada te salvará.

Respecto do primeiro punto coa memoria, hai tres cousas que poden dificultar moito a vida.

O primeiro deles é NUMA. NUMA é unha cousa que está feita para mellorar o rendemento. Dependendo da carga de traballo, pódense optimizar diferentes cousas. E na súa nova forma actual, non é moi bo para aplicacións como bases de datos que usan intensamente os búfers compartidos da caché de páxinas.

En poucas palabras. Como podes saber se algo está mal con NUMA? Ten algún tipo de golpe desagradable, de súpeto algunha CPU está sobrecargada. Ao mesmo tempo, analizas as consultas en PostgreSQL e ves que alí non hai nada semellante. Estas consultas non deberían ser tan intensivas en CPU. Podes coller isto durante moito tempo. É máis fácil usar a recomendación correcta dende o principio sobre como configurar NUMA para PostgreSQL.

Que está pasando realmente? NUMA significa Acceso a memoria non uniforme. Cal é o punto? Tes unha CPU, ao lado está a súa memoria local. E esta interconexión de memoria pode extraer memoria doutras CPU.

Se corres numactl --hardware, entón obterás unha folla tan grande. Entre outras cousas, haberá un campo de distancias. Haberá números - 10-20, algo así. Estes números non son máis que o número de saltos para coller esta memoria remota e usala localmente. En principio, unha boa idea. Isto acelera moito o rendemento baixo unha serie de cargas de traballo.

Agora imaxina que tes unha CPU primeiro intentando usar a súa memoria local, despois intentando sacar outra memoria mediante a interconexión para algo. E esta CPU obtén toda a túa caché de páxinas PostgreSQL: iso é todo, algúns gigabytes. Sempre tes o peor dos casos, porque na CPU normalmente hai pouca memoria nese módulo. E toda a memoria que é atendida pasa por estas interconexións. Resulta lento e triste. E o teu procesador que dá servizo a este nodo está constantemente sobrecargado. E o tempo de acceso desta memoria é malo, lento. Esta é a situación que non desexa se está a usar isto para unha base de datos.

Polo tanto, unha opción máis correcta para a base de datos é que o sistema operativo Linux non saiba en absoluto o que está a pasar alí. Para que acceda á memoria como o fai.

Por que é iso? Parece que debería ser ao revés. Isto ocorre por unha simple razón: necesitamos moita memoria para a caché da páxina: decenas, centos de gigabytes.

E se asignamos todo isto e almacenamos os nosos datos alí, entón a ganancia de usar a caché será significativamente maior que a ganancia dun acceso tan complicado á memoria. E así beneficiaremos incomparablemente en comparación co feito de que accederemos á memoria de forma máis eficiente mediante NUMA.

Polo tanto, hai dous enfoques aquí neste momento, ata que chegue o brillante futuro e a propia base de datos non é capaz de descubrir en que CPU está a executar e de onde ten que sacar algo.

Polo tanto, o enfoque correcto é desactivar NUMA por completo, por exemplo, ao reiniciar. Na maioría dos casos, as ganancias son de tales ordes de magnitude que non xorde en absoluto a cuestión de cal é mellor.

Hai outra opción. Usámolo con máis frecuencia que o primeiro, porque cando un cliente chega a nós para solicitar asistencia, reiniciar o servidor é un gran problema para el. Ten un negocio alí. E teñen problemas por mor da NUMA. Polo tanto, tentamos desactivalo de formas menos invasivas que o reinicio, pero teña coidado de comprobar que estea desactivado. Porque, como mostra a experiencia, é bo que desactivemos NUMA no proceso pai PostgreSQL, pero non é necesario que funcione. Necesitamos comprobar e ver que realmente se apagou.

Hai un bo post de Robert Haas. Este é un dos committers de PostgreSQL. Un dos principais desenvolvedores de todos os giblets de baixo nivel. E se segues as ligazóns desta publicación, describen varias historias coloridas sobre como NUMA fixo a vida difícil ás persoas. Mira, estuda a lista de verificación do administrador do sistema do que hai que configurar no servidor para que a nosa base de datos funcione ben. Hai que anotar e verificar estas configuracións, porque se non, non será moi boa.

Teña en conta que isto aplícase a todas as opcións das que vou falar. Pero normalmente as bases de datos recóllense en modo mestre-escravo para tolerancia a fallos. Non esquezas facer estes axustes no escravo porque algún día terás un accidente e cambiarás ao escravo e converterase no mestre.

Nunha situación de emerxencia, cando todo está moi mal, o teu teléfono soa constantemente e o teu xefe chega correndo cun pau grande, non terás tempo para pensar en comprobar. E os resultados poden ser bastante desastrosos.

O seguinte punto son páxinas enormes. As páxinas enormes son difíciles de probar por separado, e non ten sentido facelo, aínda que hai puntos de referencia que poden facelo. Son fáciles de buscar en Google.

Cal é o punto? Tes un servidor non moi caro con moita memoria RAM, por exemplo, máis de 30 GB. Non usas páxinas grandes. Isto significa que definitivamente tes sobrecarga en termos de uso da memoria. E este sobrecarga dista moito de ser o máis agradable.

Por que é iso? Entón, que está pasando? O sistema operativo asigna memoria en pequenas pezas. É tan cómodo, así aconteceu historicamente. E se entramos en detalles, o SO debe traducir enderezos virtuais a físicos. E este proceso non é o máis sinxelo, polo que o SO almacena na caché o resultado desta operación no búfer de tradución Lookaside (TLB).

E dado que o TLB é unha caché, nesta situación xorden todos os problemas inherentes a unha caché. En primeiro lugar, se tes moita memoria RAM e está todo asignado en pequenos anacos, entón este búfer faise moi grande. E se a caché é grande, a busca é máis lenta. A sobrecarga é saudable e ocupa espazo, é dicir, a RAM está a ser consumida por algo incorrecto. Esta vez.

Dous: canto máis crece a caché nunha situación así, máis probable é que teñas fallas de caché. E a eficiencia desta caché diminúe rapidamente a medida que aumenta o seu tamaño. Polo tanto, os sistemas operativos presentaron un enfoque sinxelo. Utilizouse en Linux durante moito tempo. Apareceu en FreeBSD non hai moito tempo. Pero estamos a falar de Linux. Estas son páxinas enormes.

E aquí hai que ter en conta que as páxinas enormes, como idea, foron inicialmente impulsadas por comunidades que incluían a Oracle e IBM, é dicir, os fabricantes de bases de datos pensaron firmemente que isto tamén sería útil para as bases de datos.

E como se pode facer isto amigo de PostgreSQL? En primeiro lugar, as páxinas enormes deben estar habilitadas no núcleo de Linux.

En segundo lugar, deben especificarse explícitamente polo parámetro sysctl - cantos hai. Os números aquí son dalgún servidor antigo. Podes calcular cantos búfers compartidos tes para que poidan caber alí páxinas enormes.

E se todo o teu servidor está dedicado a PostgreSQL, entón un bo punto de partida é destinar ou ben o 25% da RAM a búfers compartidos ou o 75% se estás seguro de que a túa base de datos encaixará definitivamente neste 75%. Punto de partida un. E considera, se tes 256 GB de RAM, entón, en consecuencia, terás 64 GB de búfers grandes. Calcule aproximadamente con algunha marxe: cal debe establecerse esta cifra.

Antes da versión 9.2 (se non me equivoco, dende a versión 8.2), era posible conectar PostgreSQL con páxinas enormes usando unha biblioteca de terceiros. E isto debe facerse sempre. En primeiro lugar, necesitas o núcleo para poder asignar páxinas enormes correctamente. E, en segundo lugar, para que a aplicación que traballa con eles poida utilizalos. Non só se usará así. Dado que PostgreSQL asignou memoria no estilo do sistema 5, isto podería facerse usando libhugetlbfs - este é o nome completo da biblioteca.

Na versión 9.3, o rendemento de PostgreSQL mellorouse ao traballar con memoria e abandonouse o método de asignación de memoria do sistema 5. Todo o mundo estaba moi contento, porque se non, tentas executar dúas instancias de PostgreSQL nunha máquina e di que non teño suficiente memoria compartida. E di que hai que corrixir sysctl. E hai tal sysctl que aínda necesitas reiniciar, etc. En xeral, todos estaban contentos. Pero a asignación de memoria mmap rompeu o uso de páxinas enormes. A maioría dos nosos clientes usan grandes búfers compartidos. E recomendamos encarecidamente non cambiar a 9.3, porque os gastos xerais comezaron a calcularse en boas porcentaxes.

Pero a comunidade prestou atención a este problema e en 9.4 reelaboraron moi ben este evento. E en 9.4 apareceu un parámetro en postgresql.conf no que podes activar try, on ou off.

Probar é a opción máis segura. Cando PostgreSQL se inicia, cando asigna memoria compartida, tenta coller esta memoria das enormes páxinas. E se non funciona, volve á selección normal. E se tes FreeBSD ou Solaris, podes probar, sempre é seguro.

Se está activado, simplemente non se inicia se non puido seleccionar entre as enormes páxinas. Aquí xa se trata de quen e que é máis agradable. Pero se o intentou, comprobe que realmente ten o que precisa resaltado, porque hai moito espazo para erros. Actualmente esta funcionalidade só funciona en Linux.

Unha pequena nota máis antes de ir máis lonxe. As páxinas enormes transparentes aínda non son sobre PostgreSQL. Non pode usalos normalmente. E con páxinas enormes transparentes para tal carga de traballo, cando se necesita unha gran parte de memoria compartida, os beneficios só veñen con volumes moi grandes. Se tes terabytes de memoria, isto pode entrar en xogo. Se falamos de aplicacións máis cotiás, cando tes 32, 64, 128, 256 GB de memoria na túa máquina, entón as páxinas enormes habituais están ben, e simplemente desactivamos Transparente.

E o último da memoria non está directamente relacionado coa froita, realmente pode arruinar a túa vida. Todo o rendemento verase moi afectado polo feito de que o servidor estea cambiando constantemente.

E isto será moi desagradable de varias maneiras. E o principal problema é que os núcleos modernos compórtanse de forma lixeiramente diferente dos núcleos Linux máis antigos. E isto é bastante desagradable de pisar, porque cando falamos dalgún tipo de traballo con intercambio, remata coa chegada intempestiva do asasino OOM. E o asasino OOM, que non chegou a tempo e deixou caer PostgreSQL, é desagradable. Todo o mundo saberá disto, é dicir, ata o último usuario.

Que pasa? Tes unha gran cantidade de RAM alí, todo funciona ben. Pero por algún motivo, o servidor colócase no intercambio e ralentízase por iso. Parece que hai moita memoria, pero isto pasa.

Anteriormente, aconsellamos establecer vm.swappiness en cero, é dicir, desactivar o intercambio. Anteriormente, parecía que 32 GB de RAM e os correspondentes búfers compartidos eran unha cantidade enorme. O obxectivo principal do intercambio é ter un lugar onde botar a codia se nos caemos. E xa non se cumpriu especialmente. E entón que vas facer con esta codia? Esta é unha tarefa na que non está moi claro por que é necesario o intercambio, especialmente de tal tamaño.

Pero nas versións máis modernas, é dicir, as terceiras versións do núcleo, o comportamento cambiou. E se estableces o intercambio en cero, é dicir, desactivalo, tarde ou cedo, aínda que quede algo de RAM, un asasino de OOM chegará a ti para matar aos consumidores máis intensivos. Porque considerará que con tanta carga de traballo aínda nos queda un pouco e saltaremos, é dicir, non para cravar o proceso do sistema, senón para cravar algo menos importante. Este menos importante será o consumidor intensivo de memoria compartida, é dicir, o director de correos. E despois diso será bo se a base non ten que ser restaurada.

Polo tanto, agora o predeterminado, polo que recordo, a maioría das distribucións están nalgún lugar ao redor de 6, é dicir, en que momento debería comezar a usar o intercambio dependendo da cantidade de memoria que quede. Agora recomendamos establecer vm.swappiness = 1, porque isto practicamente desactiva, pero non dá os mesmos efectos que cun OOM-killer que chegou inesperadamente e matou todo.

Que segue? Cando falamos do rendemento das bases de datos e pouco a pouco avanzamos cara aos discos, todos comezan a coller a cabeza. Porque a verdade de que o disco é lento e a memoria rápida é familiar para todos dende a infancia. E todo o mundo sabe que a base de datos terá problemas de rendemento do disco.

O principal problema de rendemento de PostgreSQL asociado aos picos de puntos de control non se produce porque o disco é lento. Isto é moi probable que se deba ao feito de que a memoria e o ancho de banda do disco non están equilibrados. Non obstante, poden non estar equilibrados en diferentes lugares. PostgreSQL non está configurado, o SO non está configurado, o hardware non está configurado e o hardware é incorrecto. E este problema non ocorre só se todo ocorre como debería, é dicir, ou non hai carga ou a configuración e o hardware están ben seleccionados.

Que é e que aspecto ten? Normalmente as persoas que traballan con PostgreSQL entraron neste asunto máis dunha vez. Vou explicar. Como dixen, PostgreSQL fai periodicamente puntos de control para volcar páxinas sucias na memoria compartida ao disco. Se temos unha gran cantidade de memoria compartida, o punto de control comeza a ter un impacto intenso no disco, porque volca estas páxinas con fsync. Chega ao búfer do núcleo e escríbese nos discos mediante fsync. E se o volume deste negocio é grande, entón podemos observar un efecto desagradable, é dicir, unha utilización moi grande de discos.

Aquí teño dúas imaxes. Agora vou explicar o que é. Estes son dous gráficos correlacionados co tempo. O primeiro gráfico é a utilización do disco. Aquí chega a case o 90% neste momento. Se tes un fallo na base de datos con discos físicos, cunha utilización do controlador RAID ao 90%, esta é unha mala noticia. Isto significa que un pouco máis e chegará a 100 e a E/S pararase.

Se tes unha matriz de discos, entón é unha historia un pouco diferente. Depende de como estea configurado, de que tipo de matriz sexa, etc.

E paralelamente, aquí configúrase un gráfico da vista interna de postgres, que indica como ocorre o punto de control. E a cor verde aquí mostra cantos búfers, estas páxinas sucias, chegaron nese momento a este punto de control para a sincronización. E isto é o principal que debes saber aquí. Vemos que aquí temos moitas páxinas e nalgún momento chegamos ao taboleiro, é dicir, escribimos e escribimos, aquí o sistema de discos está claramente moi ocupado. E o noso punto de control ten un impacto moi forte no disco. Idealmente, a situación debería parecerse máis a esta, é dicir, tivemos menos gravación aquí. E podemos solucionalo coa configuración para que siga sendo así. É dicir, a reciclaxe é pequena, pero nalgún lugar estamos escribindo algo aquí.

Que hai que facer para superar este problema? Se detivo IO na base de datos, isto significa que todos os usuarios que acudiron a cumprir as súas solicitudes agardarán.

Se miras dende o punto de vista de Linux, se tomaches un bo hardware, o configuraches correctamente, configuraches PostgreSQL normalmente para que estes puntos de control se fagan con menos frecuencia, repárteos ao longo do tempo entre eles, entón entras nos parámetros predeterminados de Debian. Para a maioría das distribucións de Linux, esta é a imaxe: vm.dirty_ratio=20, vm.dirty_background_ratio=10.

Qué significa? Apareceu un demo rubor do núcleo 2.6. Pdglush, dependendo de quen estea a usar cal, que se dedica a descartar en segundo plano páxinas sucias do búfer do núcleo e descartar cando sexa necesario descartar páxinas sucias sen importar o que pase, cando o descarte de fondo non axuda.

Cando chega o fondo? Cando o 10% da memoria RAM total dispoñible no servidor está ocupado por páxinas sucias no búfer do núcleo, chámase unha función especial de cancelación en segundo plano. Por que é de fondo? Como parámetro, ten en conta cantas páxinas hai que cancelar. E, digamos, elimina N páxinas. E durante un tempo esta cousa queda durmida. E despois volve e copia algunhas páxinas máis.

Esta é unha historia extremadamente sinxela. O problema aquí é como nunha piscina, cando se vierte nun tubo, desemboca noutro. Chegou o noso punto de control e se enviou algunhas páxinas sucias para descartar, entón gradualmente todo o asunto resolverase perfectamente desde o búfer do núcleo pgflush.

Se estas páxinas sucias seguen acumulándose, acumúlanse ata un 20%, despois de que a prioridade do SO é borrar todo no disco, porque fallará a enerxía e todo será malo para nós. Perderemos estes datos, por exemplo.

Cal é o truco? O truco é que estes parámetros no mundo moderno son o 20 e o 10% da memoria RAM total que hai na máquina, son absolutamente monstruosos en canto ao rendemento de calquera sistema de disco que teña.

Imaxina que tes 128 GB de RAM. 12,8 GB chegan ao teu sistema de disco. E non importa a caché que teña alí, non importa a matriz que teña alí, non durarán tanto.

Polo tanto, recomendámosche que axustes inmediatamente estes números en función das capacidades do teu controlador RAID. Inmediatamente fixen unha recomendación aquí para un controlador que teña 512 MB de caché.

Todo considérase moi sinxelo. Podes poñer vm.dirty_background en bytes. E estas configuracións cancelan as dúas anteriores. Ou a proporción é por defecto, ou as que teñen bytes están activadas, entón as que teñan bytes funcionarán. Pero como son consultor de DBA e traballo con diferentes clientes, intento debuxar palliñas e, polo tanto, se en bytes, entón en bytes. Ninguén deu ningunha garantía de que un bo administrador non engadiría máis memoria ao servidor, reinicialo e a cifra seguiría sendo a mesma. Só tes que calcular estes números para que todo encaixe alí cunha garantía.

Que pasa se non encaixas? Escribín que calquera lavado é efectivamente detido, pero en realidade esta é unha figura de estilo. O sistema operativo ten un gran problema: ten moitas páxinas sucias, polo que a IO que xeran os teus clientes está efectivamente detida, é dicir, a aplicación chegou a enviar unha consulta sql á base de datos, está esperando. Calquera entrada/saída a ela ten a menor prioridade, porque a base de datos está ocupada por un punto de control. E cando rematará non está completamente claro. E cando conseguiu un lavado sen fondo, significa que todo o seu IO está ocupado por el. E ata que remate, non farás nada.

Hai dous puntos máis importantes aquí que están fóra do alcance deste informe. Esta configuración debería coincidir coa configuración de postgresql.conf, é dicir, a configuración dos puntos de control. E o seu sistema de disco debe estar configurado adecuadamente. Se tes unha caché nun RAID, entón debe ter unha batería. A xente compra RAID cunha boa caché sen batería. Se tes SSD en RAID, entón deben ser de servidor, debe haber condensadores alí. Aquí tes unha lista de verificación detallada. Esta ligazón contén o meu informe sobre como configurar un disco de rendemento en PostgreSQL. Hai todas estas listas de verificación alí.

Que máis pode facer a vida moi difícil? Estes son dous parámetros. Son relativamente novos. Por defecto, pódense incluír en diferentes aplicacións. E poden facer a vida igual de difícil se se acenden incorrectamente.

Hai dúas cousas relativamente novas. Xa apareceron nos terceiros núcleos. Este é sched_migration_cost en nanosegundos e sched_autogroup_enabled, que é un por defecto.

E como arruinan a túa vida? Que é sched_migration_cost? En Linux, o planificador pode migrar un proceso dunha CPU a outra. E para PostgreSQL, que executa consultas, migrar a outra CPU non está completamente claro. Desde o punto de vista do sistema operativo, cando cambias windows entre openoffice e terminal, isto pode ser bo, pero para unha base de datos isto é moi malo. Polo tanto, unha política razoable é establecer migration_cost nun valor grande, polo menos varios miles de nanosegundos.

Que significará isto para o planificador? Considerarase que durante este tempo o proceso aínda está quente. É dicir, se tes unha transacción de longa duración que estivo facendo algo durante moito tempo, o planificador entenderao. Asumirá que ata que pase este tempo de espera, non hai necesidade de migrar este proceso a ningún lado. Se ao mesmo tempo o proceso fai algo, entón non se migrará a ningún lado, funcionará silenciosamente na CPU que se lle asignou. E o resultado é excelente.

O segundo punto é o grupo automático. Hai unha boa idea para cargas de traballo específicas que non están relacionadas coas bases de datos modernas: é dicir, agrupar os procesos polo terminal virtual desde o que se lanzan. Isto é conveniente para algunhas tarefas. Na práctica, PostgreSQL é un sistema multiproceso cun prefork que se executa desde un único terminal. Tes un escritor de bloqueo, un punto de control e todas as solicitudes dos teus clientes agruparanse nun programador por CPU. E alí agardarán ao unísono a que sexa libre, para interferir entre eles e mantelo ocupado máis tempo. Esta é unha historia que é completamente innecesaria no caso de tal carga e, polo tanto, hai que desactivala.

O meu colega Alexey Lesovsky fixo probas cun sinxelo pgbench, onde aumentou o migration_cost nunha orde de magnitude e desactivou o grupo automático. A diferenza no hardware defectuoso foi case do 10%. Hai unha discusión sobre a lista de correo de postgres onde a xente dá resultados de cambios similares na velocidade de consulta influíu nun 50%. Hai moitas historias deste tipo.

E por último, sobre a política de aforro de enerxía. O bo é que Linux agora se pode usar nun portátil. E supostamente usará ben a batería. Pero de súpeto resulta que isto tamén pode ocorrer no servidor.

Ademais, se alugas servidores dalgún hospedador, aos "bos" hospedadores non lles importa que teñas un mellor rendemento. A súa tarefa é garantir que o seu ferro se utilice da forma máis eficiente posible. Polo tanto, por defecto poden activar o modo de aforro de enerxía do portátil no sistema operativo.

Se usa este material nun servidor cunha base de datos con moita carga, entón a súa elección é acpi_cpufreq + permormance. Incluso coa demanda haberá problemas.

Intel_pstate é un controlador lixeiramente diferente. E agora dáselle preferencia a este, xa que é máis tarde e funciona mellor.

E, en consecuencia, gobernador é só rendemento. Ondemand, powersave e todo o demais non son sobre ti.

Os resultados de explicar a análise de PostgreSQL poden diferir en varias ordes de magnitude se activa o aforro de enerxía, xa que practicamente a CPU da súa base de datos funcionará dun xeito completamente imprevisible.

Estes elementos poden incluírse por defecto. Mire con atención para ver se o activaron por defecto. Isto pode ser un problema moi grande.

E, ao final, quería agradecer aos mozos do noso equipo de DBA de PosgreSQL-Consulting, Max Boguk e Alexey Lesovsky, que están facendo avances neste asunto todos os días. E intentamos facer o mellor que podemos polos nosos clientes para que todo lles funcione. É como coas instrucións de seguridade da aviación. Todo aquí está escrito con sangue. Cada unha destas noces atópase no proceso dalgún tipo de problema. Estou feliz de compartilos contigo.

Preguntas:

Grazas! Se, por exemplo, unha empresa quere aforrar cartos e colocar a base de datos e a lóxica da aplicación nun servidor, ou se a empresa segue a tendencia de moda das arquitecturas de microservizos, nas que PostgreSQL se executa nun contedor. Cal é o truco? Sysctl afectará a todo o núcleo globalmente. Non oín falar de que os sysctls se virtualicen dalgún xeito para que funcionen por separado nun contedor. Só hai un cgroup e só hai unha parte do control alí. Como podes vivir con isto? Ou se queres rendemento, executa PostgreSQL nun servidor de hardware separado e axustalo?

Respondemos á túa pregunta dunhas tres formas. Se non estamos a falar dun servidor de hardware que se poida axustar, etc., relaxa, todo funcionará ben sen esta configuración. Se tes tal carga que precisas facer estas configuracións, chegarás ao servidor de ferro antes que a estas.

Cal é o problema? Se esta é unha máquina virtual, o máis probable é que teña moitos problemas, por exemplo, co feito de que na maioría das máquinas virtuais a latencia do disco é bastante inconsistente. Aínda que o rendemento do disco sexa bo, entón unha transacción de E/S fallou que non afecta moito ao rendemento medio que ocorreu no momento do punto de control ou no momento de escribir en WAL, entón a base de datos sufrirá moito isto. E notarás isto antes de ter estes problemas.

Se tes NGINX no mesmo servidor, tamén terás o mesmo problema. Loitará pola memoria compartida. E non chegará aos problemas descritos aquí.

Pero, por outra banda, algúns destes parámetros aínda serán relevantes para ti. Por exemplo, configura dirty_ratio con sysctl para que non sexa tan tolo; en calquera caso, isto axudará. Dun xeito ou doutro, terás interacción co disco. E será segundo o patrón incorrecto. Este é xeralmente un valor predeterminado para os parámetros que mostrei. E en todo caso é mellor cambialos.

Pero pode haber problemas con NUMA. VmWare, por exemplo, funciona ben con NUMA con axustes exactamente opostos. E aquí tes que escoller: un servidor de ferro ou outro sen ferro.

Teño unha pregunta relacionada con Amazon AWS. Teñen imaxes preconfiguradas. Un deles chámase Amazon RDS. Hai algunha configuración personalizada para o seu sistema operativo?

Hai configuracións alí, pero son configuracións diferentes. Aquí configuramos o sistema operativo en termos de como a base de datos usará esta cousa. E hai parámetros que determinan a onde debemos ir agora, como o moldeado. É dicir, necesitamos tantos recursos que agora comerémolos. Despois diso, Amazon RDS reforza estes recursos e o rendemento cae alí. Hai historias individuais de como a xente comeza a meterse con este asunto. Ás veces, incluso con bastante éxito. Pero isto non ten nada que ver coa configuración do sistema operativo. É como piratear a nube. Esa é unha historia diferente.

Por que as páxinas enormes transparentes non teñen ningún efecto en comparación con Huge TLB?

Non deas. Isto pódese explicar de moitas maneiras. Pero en realidade simplemente non o dan. Cal é a historia de PostgreSQL? No inicio, asigna unha gran parte de memoria compartida. Que sexan transparentes ou non é completamente irrelevante. O feito de que destaquen ao principio explica todo. E se hai moita memoria e necesitas reconstruír o segmento shared_memory, as páxinas enormes transparentes serán relevantes. En PostgreSQL, simplemente alógase nun anaco enorme ao principio e xa está, e despois non pasa nada especial alí. Por suposto, podes usalo, pero existe a posibilidade de que a memoria compartida se corrompe cando reasigna algo. PostgreSQL non sabe disto.

Fonte: www.habr.com