por limite de núcleo de processos para aliviar o alto uso de cpu sy / kernel

Question

Meu entendimento é que o alto uso de CPU do kernel / sy é um sintoma de E / S de rede e disco ou problemas de taxa de transferência de RAM. # 516139 . No entanto, eu suspeito no caso abaixo, sobre a atribuição de threads está dando o kernel (via agendamento) muito a fazer e os cálculos reais do processo de nível de usuário estão sofrendo.

Nós construímos em paralelo muitos modelos em R sem perceber que cada função de construção de modelo é compatível com openMP e será padronizada para se distribuir (para todos os núcleos disponíveis!?).

1. Sem ter um código suspeito / mal escrito, existe uma maneira de dizer que o uso de sy é alto por causa da alocação de threads?
2. Uma vez que isso esteja em andamento, existe uma maneira de definir, por exemplo ulimit em um processo individual ou qualquer outro recurso antes de matar o processo de nível superior?

mpstat

Linux4.9.0-4-amd64(rhea.wpic.upmc.edu)01/19/2018_x86_64_(72CPU)11:27:42AMCPU%usr%nice%sys%iowait%irq%soft%steal%guest%gnice%idle11:27:42AMall13.280.0030.090.170.000.030.000.000.0056.42

iostat

Linux4.9.0-4-amd64(rhea.wpic.upmc.edu)01/19/2018_x86_64_(72CPU)avg-cpu:%user%nice%system%iowait%steal%idle13.280.0030.160.170.0056.40Device:tpskB_read/skB_wrtn/skB_readkB_wrtnsda5.90182.64532.33175621086511871712sdb4.2610.681014.2910268992975304572sdc0.8214.6820.131411168319354860sdd0.000.020.00181000

cat/proc/self/mountstats

deviceskynet:/Volumes/Phillips/mountedon/Volumes/Phillipswithfstypenfsstatvers=1.1opts:rw,vers=3,rsize=65536,wsize=65536,namlen=255,acregmin=3,acregmax=60,acdirmin=30,acdirmax=60,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=xxxxxxx,mountvers=3,mountport=748,mountproto=udp,local_lock=noneage:960031caps:caps=0x3fc7,wtmult=512,dtsize=32768,bsize=0,namlen=255sec:flavor=1,pseudoflavor=1events:2229081611145295714931563517298727855165836491305261675402401626610633220896521214276120472324067024804552381439836061553950807700000bytes:15849540514562186848723790074218539428721917628511718126404253636171RPCiostatsversion:1.0p/v:100003/3(nfs)xprt:tcp1017175006689435166887373690425626632893808021887233163595159288per-opstatisticsNULL:00000000GETATTR:22290802222909140315421351224965688721844674407337123131488830744118185897SETATTR:5616561809425648087041226008930471025591LOOKUP:1658698716586993032303132443836903464184467440734214125422932765031652035ACCESS:56304235630439081045520867565052022335312114969123526686READLINK:6083460834092453249267896269957051958788READ:11461667114618440168822858074365263724816017423512778811211438304121WRITE:4246754425923822022000265884467948064030785630990506128659735853150454CREATE:746474670148560419704968011777467071551420MKDIR:838301629621912174911642986SYMLINK:303008504792001634MKNOD:00000000REMOVE:92769278017424081335744143237439704583661RMDIR:78780130801123206878RENAME:908908021423623608029062718230095LINK:00000000READDIR:20434020434003269456460329706564232317226661771971READDIRPLUS:6343408634341001040350176310224885281465418136921691138608729FSSTAT:28342834038809647611267600532404600234FSINFO:220224328000PATHCONF:110112140000COMMIT:3588035964150299685453760410642043197411673123499

editar:

Estasituaçãoexisteporqueoopenblasépadronizadoparacálculosparalelos.veja

• link
• link

Answer 1

De relance, a média de carga 400 parece alta para uma caixa de 72 núcleos da CPU. Mais tarefas prontas para serem executadas do que os núcleos normalmente significa que algumas delas estão esperando.

A hora do sistema pode ser uma série de coisas. Para cargas de trabalho com limite de computação, como o que pode ser, a CPU do sistema de 30% parece alta.

Para ver exatamente o que está acontecendo, você pode amostrar os gráficos de chamada em todo o sistema e, em seguida, transformá-los em visualizações nítidas chamadas gráficos de chama .

# Looks like you have a Debian install
# Install debug symbols for the kernel and Linux perf
apt-get install linux-image-amd64-dbg linux-tools
git clone https://github.com/brendangregg/FlameGraph  # or download it from github
cd FlameGraph
perf record -F 99 -a -g -- sleep 60
perf script | ./stackcollapse-perf.pl > out.perf-folded
./flamegraph.pl out.perf-folded > perf-kernel.svg

Os patamares mais largos do gráfico devem indicar onde a maior parte do tempo é gasta.

O que fazer sobre isso depende do que você encontra. Eu não estou familiarizado com o openMP, mas se ele já é executado em paralelo, limite o número de trabalhos simultâneos. Não os faça lutar uns contra os outros por recursos.

800% da CPU em uma tarefa implica que você tenha tarefas multiencadeadas, usando talvez 8 núcleos. Se isso for típico, a execução de 8 ou 9 deles manterá 72 núcleos utilizados. Existem maneiras de executar scripts em paralelo até que um determinado nível de carga seja alcançado, em particular o GNU paralelo.