{"id":33707,"date":"2019-10-31T21:54:17","date_gmt":"2019-10-31T18:54:17","guid":{"rendered":"https:\/\/prohoster.info\/blog\/inogda-bolshe-eto-menshe-kogda-umenshenie-nagruzki-privodit-k-uvelicheniyu-zaderzhki\/"},"modified":"2019-10-31T21:54:17","modified_gmt":"2019-10-31T18:54:17","slug":"inogda-bolshe-eto-menshe-kogda-umenshenie-nagruzki-privodit-k-uvelicheniyu-zaderzhki","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/inogda-bolshe-eto-menshe-kogda-umenshenie-nagruzki-privodit-k-uvelicheniyu-zaderzhki","title":{"rendered":"A volte di pi\u00f9 \u00e8 di meno. Quando la riduzione del carico porta a un aumento della latenza","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Come nel nella maggior parte dei post<\/a><\/noindex>, \u00e8 sorto un problema con un servizio distribuito, chiamiamolo Elvin. Questa volta non ho scoperto il problema da solo, me lo hanno comunicato i ragazzi del lato client.<\/p>\n

Una volta mi sono svegliato a causa di una lettera di lamentela per le lunghe attese con Elvin, che avevamo pianificato di avviare a breve. In particolare, il cliente ha affrontato un ritardo del 99\u00b0 percentile di circa 50 ms, ben al di sopra del nostro budget di latenza. Era sorprendente, dato che avevo testato accuratamente il servizio, soprattutto per quanto riguardava la latenza, argomento di frequenti lamentele.<\/p>\n

Prima di consegnare Elvin per i test, ho condotto molti esperimenti con 40.000 richieste al secondo (QPS), tutti hanno mostrato una latenza di meno di 10 ms. Ero pronto a dichiarare che non ero d'accordo con i loro risultati. Ma guardando di nuovo la lettera, ho notato qualcosa di nuovo: non ho effettivamente testato le condizioni che hanno menzionato, il loro QPS era molto inferiore al mio. Ho testato a 40k QPS, mentre loro solo a 1k. Ho eseguito un altro esperimento, stavolta con un QPS pi\u00f9 basso, solo per accontentarli.
\n<\/a><\/noindex>
\nDato che sto scrivendo di questo nel blog - probabilmente lo avete gi\u00e0 capito: i loro dati si sono rivelati corretti. Ho controllato il mio cliente virtuale ripetutamente, sempre con lo stesso risultato: un numero basso di richieste non solo aumenta la latenza, ma accresce anche il numero di richieste con latenza superiore a 10 ms. In altre parole, mentre a 40k QPS circa 50 richieste al secondo superavano i 50 ms, a 1k QPS ogni secondo c'erano 100 richieste oltre i 50 ms. Paradossale!<\/p>\n

\"A
\n<\/p>\n

Stringiamo il cerchio dei sospetti<\/h1>\n

\nAffrontando un problema di latenza in un sistema distribuito con molti componenti, il primo passo \u00e8 stilare un breve elenco di sospetti. Scaviamo un po' pi\u00f9 a fondo nell'architettura di Elvin:<\/p>\n

\"A
\n
\nUn buon punto di partenza \u00e8 la lista delle transizioni di input\/output eseguite (chiamate di rete\/cerca su disco, ecc.). Cerchiamo di capire dove sia la latenza. Oltre all'ovvia I\/O con il cliente, Elvin fa un passaggio aggiuntivo: accede a un sistema di archiviazione dati. Tuttavia, questo sistema di archiviazione opera nello stesso cluster di Elvin, quindi l\u00ec la latenza dovrebbe essere inferiore a quella con il cliente. Quindi, l'elenco dei sospetti:<\/p>\n

    \n
  1. Chiamata di rete dal cliente a Elvin.\n<\/li>\n
  2. Chiamata di rete da Elvin al sistema di archiviazione dati.\n<\/li>\n
  3. Ricerca su disco nel sistema di archiviazione dati.\n<\/li>\n
  4. Chiamata di rete dal data store a Elvin.\n<\/li>\n
  5. Chiamata di rete da Elvin al cliente.<\/li>\n<\/ol>\n

    \nProviamo a escludere alcuni punti.<\/p>\n

    Il data store non c'entra nulla<\/h3>\n

    \nPer prima cosa ho trasformato Elvin in un server ping-ping, che non elabora richieste. Ricevuta una richiesta, restituisce una risposta vuota. Se la latenza diminuisce, \u00e8 un errore nell'implementazione di Elvin o del data store - nulla di strano. Nel primo esperimento otteniamo questo grafico:<\/p>\n

    \"A
    \n
    \nCome vediamo, utilizzando il server ping-ping non ci sono miglioramenti. Ci\u00f2 significa che il data store non aumenta la latenza, e la lista dei sospettati si riduce della met\u00e0:<\/p>\n

      \n
    1. Chiamata di rete dal cliente a Elvin.\n<\/li>\n
    2. Chiamata di rete da Elvin al cliente.<\/li>\n<\/ol>\n

      \nFantastico! La lista si accorcia rapidamente. Pensavo di aver quasi scoperto la causa.<\/p>\n

      gRPC<\/h3>\n

      \n\u00c8 ora di presentarvi un nuovo giocatore: gRPC<\/a><\/noindex>. \u00c8 una libreria open source di Google per la comunicazione interprocesso RPC<\/a><\/noindex>. Sebbene gRPC<\/code> sia ben ottimizzata e ampiamente utilizzata, io l'ho usata per la prima volta in un sistema di tale grandezza, e mi aspettavo che la mia implementazione fosse subottimale - per usare un eufemismo.<\/p>\n

      La presenza di gRPC<\/code> nel stack ha sollevato una nuova domanda: pu\u00f2 essere che sia la mia implementazione o che gRPC<\/code> causi il problema della latenza? Aggiungiamo un nuovo sospettato alla lista:<\/p>\n

        \n
      1. Il cliente chiama la libreria gRPC<\/code>\n<\/li>\n
      2. La libreria gRPC<\/code> sul cliente esegue una chiamata di rete della libreria gRPC<\/code> sul server\n<\/li>\n
      3. La libreria gRPC<\/code> si rivolge a Elvin (l'operazione non \u00e8 presente nel caso del server ping-pong)<\/li>\n<\/ol>\n

        \nPer farvi capire com'\u00e8 il codice, la mia implementazione del cliente\/Elvin non differisce molto dagli esempi client-server async<\/a><\/noindex>.<\/p>\n

        Nota: la lista sopra riportata \u00e8 leggermente semplificata, poich\u00e9 gRPC<\/code> consente l'uso di un proprio (modello?) di threading, in cui si intrecciano stack di esecuzione gRPC<\/code> e implementazione dell'utente. Per semplicit\u00e0, seguiremo questo modello.<\/i><\/p><\/blockquote>\n

        <\/p>\n

        Il profiling risolver\u00e0 tutto<\/h3>\n

        \nEscludendo i data store, ho pensato di essere quasi arrivato alla conclusione: \u00abAdesso \u00e8 facile! Applichiamo il profilo e vediamo dove si verifica la latenza\u00bb. Io sono un grande sostenitore del profiling preciso<\/a><\/noindex>, perch\u00e9 la CPU \u00e8 molto veloce e raramente \u00e8 il collo di bottiglia. La maggior parte delle latenze si verifica quando il processore deve fermarsi per fare altro. Il profiling preciso della CPU serve proprio a questo: registra esattamente tutti i cambi di contesto<\/a><\/noindex> e fa capire dove si verificano le latenze.<\/p>\n

        Ho preso quattro profili: uno per QPS alto (bassa latenza) e uno con un server ping-pong a basso QPS (alta latenza), sia sul lato client che sul lato server. E, giusto per sicurezza, ho preso anche un campione del profilo CPU. Quando confronto i profili, di solito cerco uno stack di chiamate anomalo. Ad esempio, sul lato con alta latenza ci sono molti pi\u00f9 switch di contesto (10 volte di pi\u00f9 o pi\u00f9). Ma nel mio caso, il numero di switch di contesto era praticamente lo stesso. Con mio grande stupore, non c'era nulla di sostanziale.<\/p>\n

        Ulteriore debug<\/h1>\n

        \nEro in preda alla disperazione. Non sapevo quali altri strumenti poter usare, e il mio piano successivo consisteva essenzialmente nel ripetere esperimenti con varie variazioni, piuttosto che una diagnosi chiara del problema.<\/p>\n

        E se<\/h3>\n

        \nFin dall'inizio ero preoccupato per un tempo di latenza di 50 ms. \u00c8 un tempo molto lungo. Ho deciso di ritagliare pezzi di codice finch\u00e9 non sarei riuscito a capire esattamente quale parte stava causando questo errore. Poi segu\u00ec un esperimento che ha funzionato.<\/p>\n

        Come al solito, a posteriori tutto sembra ovvio. Ho messo il cliente su una macchina con Alvin e ho inviato una richiesta a localhost<\/code>. E la latenza aumentata \u00e8 scomparsa!<\/p>\n

        \"A
        \n
        \nC'era qualcosa che non andava con la rete.<\/p>\n

        Acquisire competenze da ingegnere di rete<\/h3>\n

        \nDevo ammettere: la mia conoscenza delle tecnologie di rete \u00e8 terribile, soprattutto considerando che ci lavoro ogni giorno. Ma la rete era il principale sospettato, e dovevo imparare come debugarla.<\/p>\n

        Per fortuna, Internet premia coloro che vogliono imparare. La combinazione di ping e tracert sembrava un buon inizio per debuggare i problemi di trasporto di rete.<\/p>\n

        Per prima cosa, ho eseguito PsPing<\/a><\/noindex> sulla porta TCP di Alvin. Ho utilizzato i parametri predefiniti \u2014 nulla di speciale. Su oltre mille ping, nessuno ha superato 10 ms, tranne il primo per il riscaldamento. Questo contraddice l'aumento di latenza osservato di 50 ms nel 99\u00b0 percentile: per ogni 100 richieste avremmo dovuto vedere circa una richiesta con latenza di 50 ms.<\/p>\n

        Poi ho provato tracert<\/a><\/noindex>: forse il problema era in uno dei nodi lungo il percorso tra Alvin e il cliente. Ma anche il tracer \u00e8 tornato a mani vuote.<\/p>\n

        Cos\u00ec, la causa della latenza non era il mio codice, n\u00e9 l'implementazione di gRPC n\u00e9 la rete. Cominciavo gi\u00e0 a preoccuparmi di non capirlo mai.<\/p>\n

        Ora, su quale OS ci troviamo<\/h3>\n

        \ngRPC<\/code> \u00e8 ampiamente usato in Linux, ma per Windows \u00e8 un'eccezione. Ho deciso di fare un esperimento, che ha avuto successo: ho creato una macchina virtuale Linux, ho compilato Alvin per Linux e l'ho distribuita.<\/p>\n

        \"A
        \n
        \nEcco cosa \u00e8 successo: nel server ping-pong Linux non c'erano ritardi come in un nodo Windows equivalente, anche se la fonte dei dati era la stessa. Si \u00e8 scoperto che il problema era nell'implementazione di gRPC per Windows.<\/p>\n

        L'algoritmo di Nagle<\/h3>\n

        \nPer tutto questo tempo ho pensato che mi mancasse un flag gRPC<\/code>. Ora ho capito che in realt\u00e0 mi mancava il flag gRPC<\/code> Windows. Ho trovato una libreria RPC interna, nella quale ero sicuro funzionasse bene per tutti i flag installati Winsock<\/a><\/noindex>. Poi ho aggiunto tutti questi flag in gRPC e ho distribuito Alvin su Windows, nel server ping-pong corretto su Windows!<\/p>\n

        \"A
        \n
        \nQuasi<\/i> pronto: ho iniziato a rimuovere i flag aggiunti uno alla volta, finch\u00e9 non \u00e8 stata ripristinata la regressione, cos\u00ec ho potuto identificare esattamente la causa. Era il tristemente famoso         TCP_NODELAY<\/a><\/noindex>, switch dell'algoritmo di Nagle.<\/p>\n

        L'algoritmo di Nagle<\/a><\/noindex> cerca di ridurre il numero di pacchetti inviati sulla rete, ritardando la trasmissione dei messaggi finch\u00e9 la dimensione del pacchetto non supera un certo numero di byte. Anche se questo pu\u00f2 essere vantaggioso per l'utente medio, \u00e8 distruttivo per i server in tempo reale, poich\u00e9 il sistema operativo ritarder\u00e0 alcuni messaggi, causando ritardi a basso QPS. Su gRPC<\/code> era impostato questo flag nell'implementazione Linux per le socket TCP, ma non per Windows. Ho corretto<\/a><\/noindex>.<\/p>\n

        Conclusione<\/h1>\n

        \nUn grande ritardo a basso QPS \u00e8 stato causato dall'ottimizzazione del sistema operativo. Guardando indietro, il profiling non ha rilevato il ritardo, perch\u00e9 avveniva in modalit\u00e0 kernel, non in modalit\u00e0 utente<\/a><\/noindex>. Non so se si possa osservare l'algoritmo di Nagle attraverso le acquisizioni ETW, ma sarebbe interessante.<\/p>\n

        Per quanto riguarda l'esperimento localhost, probabilmente non riguardava il codice di rete effettivo, e l'algoritmo di Nagle non \u00e8 stato attivato, quindi i problemi di latenza sono scomparsi quando il client ha contattato Alvin tramite localhost.<\/p>\n

        La prossima volta che vedrete un aumento della latenza con una diminuzione del numero di richieste al secondo, l'algoritmo di Nagle dovrebbe essere nella vostra lista dei sospetti!
        \n
        Fonte:         habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

        \u041a\u0430\u043a \u0438 \u0432 \u0431\u043e\u043b\u044c\u0448\u0438\u043d\u0441\u0442\u0432\u0435 \u043f\u043e\u0441\u0442\u043e\u0432, \u043f\u043e\u044f\u0432\u0438\u043b\u0430\u0441\u044c \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430 \u0441 \u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0451\u043d\u043d\u043e\u0439 \u0441\u043b\u0443\u0436\u0431\u043e\u0439, \u043d\u0430\u0437\u043e\u0432\u0451\u043c \u044d\u0442\u0443 \u0441\u043b\u0443\u0436\u0431\u0443 \u042d\u043b\u0432\u0438\u043d. \u041d\u0430 \u044d\u0442\u043e\u0442 \u0440\u0430\u0437 \u044f \u043d\u0435 \u0441\u0430\u043c \u043e\u0431\u043d\u0430\u0440\u0443\u0436\u0438\u043b \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0443, \u043c\u043d\u0435 \u0441\u043e\u043e\u0431\u0449\u0438\u043b\u0438 \u0440\u0435\u0431\u044f\u0442\u0430 \u0441 \u043a\u043b\u0438\u0435\u043d\u0442\u0441\u043a\u043e\u0439 \u0447\u0430\u0441\u0442\u0438. \u041e\u0434\u043d\u0430\u0436\u0434\u044b \u044f \u043f\u0440\u043e\u0441\u043d\u0443\u043b\u0441\u044f \u043e\u0442 \u043d\u0435\u0434\u043e\u0432\u043e\u043b\u044c\u043d\u043e\u0433\u043e \u043f\u0438\u0441\u044c\u043c\u0430 \u0438\u0437-\u0437\u0430 \u0431\u043e\u043b\u044c\u0448\u0438\u0445 \u0437\u0430\u0434\u0435\u0440\u0436\u0435\u043a \u0443 \u042d\u043b\u0432\u0438\u043d\u0430, \u043a\u043e\u0442\u043e\u0440\u043e\u0433\u043e \u043c\u044b \u043f\u043b\u0430\u043d\u0438\u0440\u043e\u0432\u0430\u043b\u0438 \u0437\u0430\u043f\u0443\u0441\u0442\u0438\u0442\u044c \u0432 \u0431\u043b\u0438\u0436\u0430\u0439\u0448\u0435\u0435 \u0432\u0440\u0435\u043c\u044f. \u0412 \u0447\u0430\u0441\u0442\u043d\u043e\u0441\u0442\u0438, \u043a\u043b\u0438\u0435\u043d\u0442 \u0441\u0442\u043e\u043b\u043a\u043d\u0443\u043b\u0441\u044f \u0441 \u0437\u0430\u0434\u0435\u0440\u0436\u043a\u043e\u0439 99-\u0433\u043e \u043f\u0440\u043e\u0446\u0435\u043d\u0442\u0438\u043b\u044f \u0432 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":25389,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-33707","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47A volte di pi\u00f9 significa di meno. Quando la diminuzione del carico porta a un aumento della latenza | ProHoster","description":"Come spesso accade nella maggior parte dei post, c'\u00e8 stato un problema con il servizio distribuito, chiamiamo questo servizio Alvin.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/inogda-bolshe-eto-menshe-kogda-umenshenie-nagruzki-privodit-k-uvelicheniyu-zaderzhki","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0418\u043d\u043e\u0433\u0434\u0430 \u0431\u043e\u043b\u044c\u0448\u0435 \u2014 \u044d\u0442\u043e \u043c\u0435\u043d\u044c\u0448\u0435. \u041a\u043e\u0433\u0434\u0430 \u0443\u043c\u0435\u043d\u044c\u0448\u0435\u043d\u0438\u0435 \u043d\u0430\u0433\u0440\u0443\u0437\u043a\u0438 \u043f\u0440\u0438\u0432\u043e\u0434\u0438\u0442 \u043a \u0443\u0432\u0435\u043b\u0438\u0447\u0435\u043d\u0438\u044e \u0437\u0430\u0434\u0435\u0440\u0436\u043a\u0438 | ProHoster","og:description":"\u041a\u0430\u043a \u0438 \u0432 \u0431\u043e\u043b\u044c\u0448\u0438\u043d\u0441\u0442\u0432\u0435 \u043f\u043e\u0441\u0442\u043e\u0432, \u043f\u043e\u044f\u0432\u0438\u043b\u0430\u0441\u044c \u043f\u0440\u043e\u0431\u043b\u0435\u043c\u0430 \u0441 \u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0451\u043d\u043d\u043e\u0439 \u0441\u043b\u0443\u0436\u0431\u043e\u0439, \u043d\u0430\u0437\u043e\u0432\u0451\u043c \u044d\u0442\u0443 \u0441\u043b\u0443\u0436\u0431\u0443 \u042d\u043b\u0432\u0438\u043d.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/inogda-bolshe-eto-menshe-kogda-umenshenie-nagruzki-privodit-k-uvelicheniyu-zaderzhki","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:54:17+00:00","article:modified_time":"2019-10-31T18:54:17+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"33707","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 16:23:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:35:31","updated":"2026-01-21 16:23:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/33707","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=33707"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/33707\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/25389"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=33707"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=33707"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=33707"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}