Numero ottimale di processi unicorno per CPU

Stiamo eseguendo un'app Web Ruby on Rails sotto Unicorn. La nostra app non è strettamente legata alla CPU (abbiamo un doppio sistema Xeon E5645 con 12 core e un valore medio di carico di picco è di circa 6). Inizialmente abbiamo iniziato con 40 lavoratori Unicorn ma il footprint della memoria dell'applicazione è aumentato nel tempo. Quindi, ora dobbiamo ridurre il numero di processi di lavoro. Ho pensato che la formula standard (numero di core della CPU + 1) si applica anche a Unicorn, ma il mio collega ha cercato di convincermi che dovremmo riservare più istanze Unicorn per CPU e fornito questo link . Tuttavia, non sono esattamente sicuro del motivo per cui dobbiamo spendere così tanta memoria sui processi inattivi di Unicorn.

La mia domanda è: qual è il motivo per avere più di un'istanza Unicorn per core della CPU? È dovuto ad alcune peculiarità architettoniche dell'unicorno? Sono consapevole che i processi Unicorn occupati non possono accettare nuove connessioni (stiamo usando socket di dominio UNIX per comunicare con istanze Unicorn BTW) ma ho pensato che il backlog fosse stato introdotto esattamente per risolvere questo problema. È comunque possibile superare da 2 a 8 istanze Unicorn per regola CPU?

Ok, ho finalmente trovato la risposta. Il numero ottimale di lavoratori Unicorn non è direttamente collegato al numero di core della CPU, dipende dal carico e dalla struttura / reattività dell'app interna. Fondamentalmente utilizziamo il profiler di campionamento per determinare lo stato dei lavoratori, cerchiamo di mantenere i lavoratori inattivi al 70% e il 30% a svolgere il lavoro effettivo. Pertanto, il 70% dei campioni dovrebbe essere "in attesa sulla chiamata select () per ottenere una richiesta dal server frontend". La nostra ricerca ha dimostrato che ci sono solo 3 stati effettivi di lavoratori: lo 0-30% dei campioni è inattivo, il 30-50% dei campioni è inattivo e il 50-70% dei campioni è inattivo (sì, possiamo ottenere più campioni inattivi ma lì non ha senso in questo perché la reattività delle applicazioni non cambia in modo significativo). Consideriamo la situazione dello 0-30% una "zona rossa" e la situazione del 30-50% una "zona gialla".

Hai ragione su N + 1 per i lavori associati alla CPU.

D'altra parte, unicorno non utilizza thread, quindi ogni IO op. blocca il processo e un altro processo può avviare e analizzare le intestazioni HTTP, concatenare le stringhe ed eseguire tutte le attività ad alta intensità di CPU necessarie per servire l'utente (eseguendolo in precedenza per ridurre la latenza delle richieste).

E potresti voler avere più thread / processi che core. Immagina la seguente situazione: req. A richiede dieci volte di più quindi req. B, hai diverse richieste A simultanee e la richiesta B veloce è appena accodata in attesa del completamento di A-req. Pertanto, se è possibile prevedere il numero di richieste pesanti, è possibile utilizzare questo numero come un'altra linea guida per ottimizzare il sistema.