We have got a new Linux el6.x86_64 server and after moving all our jobs (primarily java/C++/python/shell) processes onto this new server, we have observed the processes running slow. E.g. A python script running on previous server would finish in 30 minutes, on new server it takes 4 hours to process. Below is the CPU usage statistics (captured with top) from new server, which shows only one task active at a time. I need your help to understand following:If it has 32CPUs, shouldn't there be 32 tasks running in parallel?All these CPUs are online, verified from /sys/devices/system/cpu. Could there be any other system setting CPU availability very low? top - 02:04:04 up 5 days,  6:56, 32 users,  load average: 3.63, 3.91, 3.47Tasks: 1208 total,   1 running, 1207 sleeping,   0 stopped,   0 zombieCpu0  : 23.4%us,  3.0%sy,  0.0%ni, 73.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%stCpu1  : 15.4%us,  5.6%sy,  0.0%ni, 79.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%stCpu2  : 12.2%us,  1.0%sy,  0.0%ni, 86.8%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%stCpu3  :  3.9%us,  0.3%sy,  0.0%ni, 95.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%stCpu4  : 19.3%us,  2.0%sy,  0.0%ni, 78.4%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%stCpu5  :  6.9%us,  0.3%sy,  0.0%ni, 92.8%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%stCpu6  :  1.3%us,  0.0%sy,  0.0%ni, 98.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%stCpu7  :  0.3%us,  0.0%sy,  0.0%ni, 99.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%stCpu8  :  0.3%us,  0.3%sy,  0.0%ni, 99.0%id,  0.3%wa,  0.0%hi,  0.0%si,  0.0%stCpu9  :  0.7%us,  0.0%sy,  0.0%ni, 99.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%stCpu10 :  0.7%us,  0.0%sy,  0.0%ni, 99.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%stCpu11 :  0.7%us,  0.0%sy,  0.0%ni, 99.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%stCpu12 :  0.7%us,  0.0%sy,  0.0%ni, 99.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%stCpu13 :  1.0%us,  0.3%sy,  0.0%ni, 98.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%stCpu14 :  1.0%us,  0.0%sy,  0.0%ni, 99.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%stCpu15 :  0.7%us,  0.0%sy,  0.0%ni, 99.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%stCpu16 : 42.2%us,  4.0%sy,  0.0%ni, 53.5%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%stCpu17 :  0.7%us,  0.7%sy,  0.0%ni, 98.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%stCpu18 : 26.0%us,  2.0%sy,  0.0%ni, 71.7%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%stCpu19 :  0.7%us,  0.3%sy,  0.0%ni, 99.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%stCpu20 : 53.8%us,  4.0%sy,  0.0%ni, 41.2%id,  0.0%wa,  0.0%hi,  1.0%si,  0.0%stCpu21 : 29.3%us,  1.3%sy,  0.0%ni, 69.4%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%stCpu22 :  2.0%us,  0.7%sy,  0.0%ni, 97.4%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%stCpu23 :  0.7%us,  0.0%sy,  0.0%ni, 99.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%stCpu24 :100.0%us,  0.0%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%stCpu25 :  0.7%us,  1.0%sy,  0.0%ni, 98.4%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%stCpu26 :  0.7%us,  1.3%sy,  0.0%ni, 98.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%stCpu27 :  0.3%us,  0.0%sy,  0.0%ni, 99.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%stCpu28 :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%stCpu29 :  0.3%us,  0.0%sy,  0.0%ni, 99.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%stCpu30 :  2.6%us,  0.0%sy,  0.0%ni, 97.4%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%stCpu31 :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%stMem:  396867664k total, 391584344k used,  5283320k free,   414764k buffers
Linux: CPU load sharing on new server
arch linux;performance
The processes will not utilize the extra cores to run faster unless they are designed for it by using threads or other mechanisms for parallelism.Python in particular is typically bad at exploiting multiple cores due to the GIL (Global interpreter Lock). You could try to use the 'multiprocessing' Python module to achieve more preferment software.There is not much you can do to increase performance of single-core, not I/O bound processes, except buying CPUs with higher clock speeds. But sometimes you can find memory access and memory caching bottlenecks. For example, if your machine contains multiple CPUs that are connected together over NUMA connections, and processes move frequently between those CPUs, the situation may arise where CPUs have to frequently access memory over the NUMA connections through other CPUs (Memory connected to another CPU can be significantly slower to access then the memory connected directly to 'this' CPU).It might be worthwhile to try and pin processes to particular CPUs by using the cpuset(1) command. If this works, you should also look into the various Kenel NUMA behaviour tuning parameters.Edit to add: Another area to look at is power management, perhaps the CPU frequencies are getting scaled down because of power saving processes. You can use the cpupower(1) command to check and set VPU power management settings.