How do you check CPU info on Linux (lscpu, nproc, /proc/cpuinfo)?

Checking your CPU setup is like looking under the hood of a car before a road trip. You want to know how many cylinders you have, how fast it can go, and whether it has turbo. Linux gives you three main tools to inspect your processors at different levels of detail, and knowing which one to use when saves you time in production.

The go-to tool is lscpu. It pulls data from /sys/devices/system/cpu and /proc/cpuinfo and presents it in a clean, organized format. You will see the architecture (like x86_64 or aarch64), how many CPU sockets the server has, cores per socket, threads per core, speed ranges, the cache layout (L1, L2, L3), and whether virtualization is supported. This is the command you run first when sizing a server or filing a support ticket. The nproc command is even simpler. It just tells you how many processing units are available. This is great in scripts where you need to set how many things run at once, like passing -j$(nproc) to make, or setting worker threads for Nginx or Gunicorn.

Under the hood, all CPU info comes from the kernel detecting processors at boot time. On x86 systems, the kernel uses CPUID instructions to probe each processor and fills in the /proc/cpuinfo virtual file. Each logical processor gets its own block in this file, with details like processor number, vendor, CPU family, model, stepping, microcode version, cache size, and a flags field listing supported instruction sets like sse4_2, avx2, and aes. The sysfs tree under /sys/devices/system/cpu/ adds runtime details like current clock speed, online/offline status, and how cores map to sockets.

In real-world production, knowing your CPU layout matters a lot for performance. On a 4-socket server with 24 cores per socket and hyperthreading, you get 192 logical CPUs. But memory access speed varies based on which NUMA node (memory bank tied to a socket) a process runs on. Tools like numactl and taskset let you pin processes to specific cores so they stay close to their memory. For Kubernetes workloads, CPU limits and requests map to these physical resources, and understanding the difference between real cores and hyperthreads affects how you plan capacity. The lstopo tool from the hwloc package can draw visual maps of your CPU layout.

A common mistake is confusing logical CPUs with physical cores. If nproc says 16, you might only have 8 real cores with hyperthreading turned on. This matters for CPU-heavy work because hyperthreading only gives you about 15-30% more performance, not double. Another trap is in virtual machines, where lscpu might show what the hypervisor presents rather than the real hardware, and CPU steal time (visible in top) tells you when other VMs are competing for your CPU cycles. Always check the flags in /proc/cpuinfo to confirm the server supports specific instruction sets like AVX-512 before deploying software that needs them.