{"id":19865,"date":"2026-06-10T11:53:56","date_gmt":"2026-06-10T09:53:56","guid":{"rendered":"https:\/\/webhosting.de\/server-numa-locality-cpu-memory-affinity-optimierung-core\/"},"modified":"2026-06-10T11:53:56","modified_gmt":"2026-06-10T09:53:56","slug":"server-numa-locality-cpu-memory-affinity-optimization-core","status":"publish","type":"post","link":"https:\/\/webhosting.de\/en\/server-numa-locality-cpu-memory-affinity-optimierung-core\/","title":{"rendered":"Server NUMA Locality and CPU-Memory Affinity for maximum hosting performance"},"content":{"rendered":"<p><strong>Server NUMA<\/strong> Locality and CPU memory affinity determine how close threads work to their RAM and how constant latencies remain in hosting stacks. I show you in a practical way how you can achieve measurably more throughput with topology recognition, affinity strategies and I\/O paths close to the node and <strong>Latency<\/strong> noticeably lower.<\/p>\n\n<h2>Key points<\/h2>\n\n<p>For quick orientation, I'll summarize the key messages before explaining the steps in detail and backing them up with examples; this will allow you to see directly where you should start in order to <strong>Locality<\/strong> and Affinity profitably. I emphasize clear relationships between threads, memory and I\/O so that you can derive priorities cleanly and <strong>Decisions<\/strong> meet. I also identify scenarios in which Interleave makes sense without diluting your critical paths and show how you can demonstrate real progress via monitoring and <strong>Error<\/strong> are avoided. For virtualized environments, I provide tips on the placement of vCPUs and vRAM so that guest systems do not slide across multiple nodes and <strong>remote<\/strong>-accesses explode. Finally, I translate the findings into a short roadmap so that you can proceed in a structured manner and <strong>measurable<\/strong> secure.<\/p>\n<ul>\n  <li><strong>Locality<\/strong> first: keep threads close to your own RAM, avoid remote.<\/li>\n  <li><strong>Affinity<\/strong> fix: Bind cores and memory together by policy.<\/li>\n  <li><strong>Topology<\/strong> read: Nodes, cores, PCIe devices per socket.<\/li>\n  <li><strong>I\/O paths<\/strong> bundle: Couple NIC, NVMe and app in the same node.<\/li>\n  <li><strong>trade fairs<\/strong> instead of guessing: P95\/ P99, remote access and throughput tracking.<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/06\/serverraum-performance-1573.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Understanding the NUMA topology<\/h2>\n\n<p>Before I move workloads, I read the <strong>Topology<\/strong> of the server: How many NUMA nodes exist, how many cores and how much RAM are connected to each node. I also pay attention to which PCIe devices - such as NICs or NVMe SSDs - are connected to which socket, because this determines interrupt paths and memory accesses, and <strong>Latency<\/strong> characterized. A node provides local memory access with a short distance; anything beyond that costs time and bandwidth. The larger the machine scales with multiple sockets, the more remote access affects response times and eats up bandwidth. <strong>Throughput<\/strong>. For an understandable introduction to the hardware logic, I use a compact <a href=\"https:\/\/webhosting.de\/en\/numa-nodes-server-hosting-large-systems-serverboost\/\">NUMA nodes at a glance<\/a>, to consciously take node boundaries into account and avoid incorrect distributions.<\/p>\n\n<p>In practice, I start with a short topology inventory and document it so that I can later derive affinity decisions in a comprehensible way. Useful commands:<\/p>\n<pre><code># cores and NUMA assignment\nlscpu -e=CPU,Core,Socket,Node\n\n# NUMA hardware overview\nnumactl --hardware\n\n# Assign PCIe devices to their NUMA node\nlspci -nn | grep -E \"Ethernet|Non-Volatile\"\nfor d in \/sys\/bus\/pci\/devices\/*; do echo -n \"$d: \"; cat $d\/numa_node; done\n<\/code><\/pre>\n<p>The important thing is that you <strong>PCIe Root Complex<\/strong> and device slots to the sockets. Two ports of the same NIC can be assigned to different nodes; this influences where RX\/TX queues and IRQs land best. The same applies to NVMe: modern controllers have several queues that you should bind to cores close to the node so that DMA does not trigger any node hops.<\/p>\n\n<h2>Using CPU memory affinity correctly<\/h2>\n\n<p>With CPU-Memory Affinity, I firmly link processes to core areas and enforce local memory allocation as far as possible, so that <strong>Threads<\/strong> do not constantly reach over the edge of the node. In Linux, I define CPUs via systemd or cgroups and combine this with memory policies so that RAM is preferably created on the same node and <strong>remote<\/strong> remains minimized. Critical services - API front-ends, in-memory caches, databases - benefit immediately because memory controller wait times are reduced and cache hits are more frequent. However, pinning limits that are too hard can restrict scheduling, so I back up every adjustment with benchmarks and monitor P95\/P99 values for noticeable effects on <strong>User<\/strong>-experience. A compact introduction to Affinity in hosting helps you get started: <a href=\"https:\/\/webhosting.de\/en\/server-process-affinity-numa-awareness-hosting-ressourcentuning\/\">Affinity and NUMA awareness<\/a> provide the necessary tools for clean placement.<\/p>\n\n<p>The decisive factor is the <strong>First-touch principle<\/strong>Memory is created on the node that writes to the page first. Therefore, initialize large heaps or buffers on the target cores of the node in which the service will later run - ideally with the CPU and memory policy already set (e.g. via systemd unit or numactl). If you start cold on node 0 and then move threads to node 1, the majority of the pages remain remote. For heaps of large runtimes, it is worth using \u201epre-touch\u201c during the bootstrap so that pages rot locally and then stay warm.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/06\/server_numa_affinity_2763.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>NUMA awareness in the hosting stack<\/h2>\n\n<p>A NUMA-aware operating system, a suitable hypervisor and applications with thread pinning unfold their full potential together. <strong>Potential<\/strong>. The OS prefers local placement when free resources are available in the node, while the hypervisor allocates VMs in such a way that vCPUs and vRAM do not drift apart and <strong>Locality<\/strong> is maintained. In the application, I separate worker pools per node and keep queues local instead of operating global pools crosswise. I organize database processes, cache daemons and web server instances on a node-by-node basis so that hotpaths remain short and <strong>Jitter<\/strong> decreases. This increases consistency and predictability under load, which directly influences the predictability of SLAs in euros and saves expensive overprovisioning.<\/p>\n\n<p>At the Ingress level, I take care of <strong>Node affinity<\/strong> of the sessions, for example through sticky routing or consistent hashing (e.g. on client IP or session tokens), so that requests end up back at \u201etheir\u201c node-local worker and cache. For stateful services, I plan replicas per node and balance read access locally; I equalize write paths via asynchronous replication or batching to avoid inter-node ping-pong.<\/p>\n\n<h2>Schedule services node by node<\/h2>\n\n<p>I group the layers of a stack in such a way that each layer has a clear node reference and <strong>Paths<\/strong> stay short. A classic separation: web\/API per node, app worker next to it, plus the local cache; the database also sits close to the node if the RAM footprint fits in and <strong>IO<\/strong>-path is not interrupted. I move reporting jobs, backups or batch workers to less critical nodes so that interactive requests remain unaffected. I avoid large monolith instances because they often cross node boundaries and thus generate remote load that <strong>Performance<\/strong> blurred. Smaller, replicated instances per node often deliver better throughput in everyday use, as they respect the NUMA rules and smooth out peaks.<\/p>\n\n<p>For capacity planning, I calculate <strong>headroom<\/strong> separately for each node: CPU buffer for bursts, RAM buffer against OOM and separate margins for page cache. In this way, I prevent the kernel from unintentionally switching remotely. I define clear switchover paths for failover: If a node fails, replacement instances can run cross-node, but I limit their concurrency until the original node is restored - this keeps the overall latency stable.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/06\/server-performance-numa-locality-4759.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Setting CPU affinity: Methods and pitfalls<\/h2>\n\n<p>For core allocation, I use systemd with CPUAffinity or cgroups with cpuset.cpus, so that services have fixed <strong>Core areas<\/strong> get. When pinning, I pay attention to hyper-threading pairs, because two logical threads of a physical unit share resources and can slow each other down if I combine them unhappily and <strong>Tips<\/strong> create. Latency paths - TLS termination, API ingress, cache readers - get exclusive cores, while logs, compression or backups move to other pools. Pools that are too narrow without buffers cause queues, so I factor in headroom and check context switches, runqueue length and <strong>IRQ<\/strong>-distribution. From the observation I deduce whether I open the cores wider or concentrate them further until the latency distribution drops off cleanly and the P99 peaks become quieter.<\/p>\n\n<p>For further jitter reduction, I selectively set kernel switches such as <strong>nohz_full<\/strong> and <strong>rcu_nocbs<\/strong> for exclusive latency cores, isolate them from system services and deliberately place IRQs only on CPUs intended for this purpose. I use the \u201eirqbalance\u201c service with caution: either configure it specifically or deactivate it if it counteracts your manual IRQ affinity. I use SCHED_FIFO\/SCHED_RR sparingly and only with Be limits to avoid priority inversion or starvation.<\/p>\n\n<h2>Memory policies and NUMA masks<\/h2>\n\n<p>For the memory policy, I differentiate between preferred local allocation, interleave across multiple nodes and fixed NUMA masks via cpuset.mems, so that <strong>RAM<\/strong> flows to where threads are actually running. For interactive services, I usually set \u201epreferred\u201c, which means that the system allocates locally and only deviates when there is a shortage, which is <strong>remote<\/strong>-accesses are limited. Analytics or streaming jobs sometimes benefit from interleave because bandwidth is distributed across nodes and pressure on a controller is reduced. Fixed masks offer control, but require discipline in capacity planning so that no unwanted OOM events in a node go up and <strong>Services<\/strong> interfere. The following table assigns common policies to typical scenarios and helps you to make a quick decision.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th><strong>Policy<\/strong><\/th>\n      <th><strong>Effect<\/strong><\/th>\n      <th><strong>Typical workloads<\/strong><\/th>\n      <th><strong>Risk<\/strong><\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Preferred (local)<\/td>\n      <td>RAM primarily in the local node, fallback option in case of scarcity<\/td>\n      <td>Web\/ API, caches, OLTP databases<\/td>\n      <td>Slight drift at full load on other nodes<\/td>\n    <\/tr>\n    <tr>\n      <td>Interleave<\/td>\n      <td>Even distribution across selected nodes<\/td>\n      <td>Streaming, analytics, large scans<\/td>\n      <td>Higher latency for individual accesses<\/td>\n    <\/tr>\n    <tr>\n      <td>Fixed NUMA mask<\/td>\n      <td>Strict binding to defined memory nodes<\/td>\n      <td>Strictly encapsulated services, deterministic tests<\/td>\n      <td>Risk of OOM if the budget is planned incorrectly<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Keep an eye on system-wide switches: <strong>zone_reclaim_mode<\/strong> influences whether a node aggressively cleans up its own memory before allocating remotely - often undesirable for latency paths. <strong>Transparent Huge Pages<\/strong> (THP) can trigger page migration or generate stalls; for latency-sensitive services, I usually choose \u201emadvise\u201c and use static hugepages where it makes sense, so that TLB hits increase and page fault peaks decrease.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/06\/server_performance_optimization_2314.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Bind network and I\/O paths close to the node<\/h2>\n\n<p>I align NIC queues (RX\/ TX) so that their IRQs point to cores of the appropriate node and packet processing takes place where the <strong>App<\/strong> computes. The same applies to NVMe SSDs or RAID controllers: I\/O threads should run on the node to which the device is connected via PCIe, so that DMA paths remain short and <strong>Bottlenecks<\/strong> are missing. On Linux, I adjust IRQ affinity masks and link them to CPU pools of my services to create a continuous path. With microbursts from the network, such as many TLS handshakes, this proximity pays off directly because copy paths are shorter and CPU caches stay warm and <strong>Context<\/strong> less frequently. This creates a consistent data flow from the package to the application to the memory, without unnecessary node hops.<\/p>\n\n<p>Concrete levers in the network stack: <strong>RSS<\/strong> for hardware distribution to queues, <strong>RPS\/RFS<\/strong> for software-based CPU control and <strong>XPS<\/strong> for TX selection. I use ethtool to assign RX queues to core groups that run in the same node as your workers. For storage I use <strong>blk-mq<\/strong>-tuning and queue mapping per node; NVMe controllers offer several submission\/completion queues, which I scale and affiliate \u2264 number of cores per node. Regularly check whether interrupts (cat \/proc\/interrupts) are firing where your app cores are located - you can recognize drift by increasing remote bytes despite a stable load.<\/p>\n\n<h2>Structure application architecture in line with NUMA<\/h2>\n\n<p>At app level, I set up my own worker pools for each NUMA node, keep queues local and avoid global lock hotspots so that <strong>Threads<\/strong> do not jump back and forth. I set up session and data sharding so that hot partitions stay where the requesting workers are running and <strong>Time<\/strong> does not get lost in inter-node traffic. For caches, I often use replicas instead of a central instance so that readers hit node-local copies. In Netty, Tokio, libuv or DB clients, I pin event loops to fixed cores and pay attention to IRQ proximity so that task changes remain limited and <strong>Caches<\/strong> hit better. This layout reduces ping-pong effects and makes response times more consistent over the course of the day.<\/p>\n\n<p>One underestimated lever is <strong>allocator<\/strong> and runtime options: NUMA-aware allocators (jemalloc\/tcmalloc) reduce cross-thread contention and keep pages closer to thread home kernels. In JVM stacks, options like NUMA awareness and pre-touch help for deterministic fault phases; in .NET, I align GC threads close to nodes and pay attention to server GC to smooth stop times. In Go, I size GOMAXPROCS per node pool and keep goroutine schedulers away from latency cores that operate close to IRQ.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/06\/server_performance_desk_7452.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Sensible control of NUMA autobalancing<\/h2>\n\n<p>Automatic NUMA balancing mechanisms of the kernel can help to smooth out distributed load, but I always check whether they can handle my <strong>Affinity<\/strong> are undermined. In latency-critical services, I disable or throttle automatic moving when it pulls threads out of their local memory and <strong>Tips<\/strong> generated. For analytics jobs or broad batch processing, I tend to leave balancing on because it can increase bandwidth without degrading interaction. A practical introduction to balancing strategies provides me with additional starting points: <a href=\"https:\/\/webhosting.de\/en\/numa-balancing-server-memory-optimization-hardware-numaflux\/\">Understanding NUMA balancing<\/a> shows when the automatic system should carry and when it should be assigned manually. In the end, I make a data-based decision for each service class instead of blindly adopting a global default setting and <strong>Goals<\/strong> to miss.<\/p>\n\n<p>When balancing is activated, I monitor migration rates, minor\/major fault peaks and CPU steal per node. If pages are moved back and forth cyclically, I counter this with tighter pinning, pre-touch and narrower memory masks. In workloads with long, sequential scans, on the other hand, balancing can harmonize load as long as no interactive latency paths are affected.<\/p>\n\n<h2>Monitoring: measure, compare, decide<\/h2>\n\n<p>Without measurement, tuning remains a guessing game, so I track CPU load per core and per node, memory usage per node and the proportion of <strong>remote<\/strong>-accesses. For user experience, P95\/ P99 latencies count much more than mean values, because outliers shape SLA impressions and <strong>Costs<\/strong> upwards. I run realistic load profiles with cold and warm caches because both worlds show different bottlenecks. After each change, I document the settings, test date and results so that I can safely reverse modifications later and <strong>Knowledge<\/strong> is not lost. If you also correlate app metrics - queue lengths, retries, garbage collection - alongside system values, you can recognize cause and effect more quickly.<\/p>\n\n<p>Practical help in the analysis:<\/p>\n<ul>\n  <li>numastat (system- and process-related) for local vs. <strong>remote<\/strong>-Hit<\/li>\n  <li>\/proc\/interrupts and SoftIRQ time after CPU for IRQ drift<\/li>\n  <li>perf events and scheduler statistics for runqueue depth, context switches, LLC misses, etc.<\/li>\n  <li>fio\/iperf\/wrk with node-specific worker pools for reproducible comparisons<\/li>\n<\/ul>\n<p>The evaluation is done per node: I expect latency histograms to be close together. If a node moves upwards, I first look for incorrectly distributed IRQ load, drift in the page cache or heaps that were allocated to the wrong node during warm-up.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/06\/hosting-serverraum-8372.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>NUMA in VMs and containers<\/h2>\n\n<p>In virtualization, the placement of vCPUs and vRAM on a common node is important so that the guest workloads do not fray and <strong>Latency<\/strong> pulls up. I dimension RAM so that it fits into the local node, and avoid large VMs that span several nodes and require a lot of RAM. <strong>Drift<\/strong> trigger. For containers, I use cpuset controllers so that pod groups work consistently on one node and storage is created locally. I prefer to place I\/O-heavy guests on the node with a direct storage connection in order to keep DMA paths short and <strong>IRQ<\/strong>-reduce noise. This means that even dense virtualization hosts remain predictable and carry more projects on the same hardware.<\/p>\n\n<p>I pay attention to <strong>vNUMA<\/strong>-Exposure: The guest should see the same node structure that the hypervisor physically provides. vCPU pinning and vRAM binding belong together; I move hot-adds during maintenance windows if possible, because otherwise new pages end up remotely. In Kubernetes, I set to \u201eguaranteed\u201c QoS, CPU manager \u201estatic\u201c and topology-aware placement so that pods do not move across nodes. For SR-IOV\/VFs, I assign VFs to the appropriate physical node and bind the IRQ queues to the CPU sets of the pods or VMs they serve.<\/p>\n\n<h2>Targeted preparation of first touch, warm-up and heaps<\/h2>\n\n<p>Many performance errors occur during <strong>Start<\/strong>Heaps grow in the warm-up phase where the first requests land - often centrally on a node. I therefore run controlled warmups for each node: start instances with the CPU\/memory mask set, execute targeted pre-load queries and initialize caches in parallel for each node. For JVM services, I activate pre-touch of the heap; for databases, I segment buffer pools node by node. This reduces subsequent page migrations and ensures that the first requests do not randomly shape the memory distribution.<\/p>\n\n<h2>Kernel\/BIOS tuning for constant latencies<\/h2>\n\n<p>Under the hood, I adjust the power and interrupt policy:<\/p>\n<ul>\n  <li>Set CPU governor to \u201eperformance\u201c, limit deep C-states, use package C-states carefully in order to <strong>Jitter<\/strong> to reduce.<\/li>\n  <li>Do not throttle memory frequency; balanced energy profiles often reduce <strong>Throughput<\/strong> under load.<\/li>\n  <li>Avoid spread spectrum\/clock modulation if consistency is more important than minimal energy savings.<\/li>\n<\/ul>\n<p>At kernel level, I keep housekeeping CPUs separate from latency cores, minimize timer interrupts on hot cores (nohz_full) and park background work (compaction, Kswapd) preferably on system cores of a node that does not run latency paths.<\/p>\n\n<h2>Troubleshooting and typical anti-patterns<\/h2>\n\n<ul>\n  <li><strong>Symptom<\/strong>P99 latency jumps after deploys. <strong>Cause<\/strong>Heaps\/Caches first-touch on wrong node. <strong>Solution<\/strong>Warmup\/Pre-Touch under target affinity, then open load distributor.<\/li>\n  <li><strong>Symptom<\/strong>High SoftIRQ time on \u201ewrong\u201c CPUs. <strong>Cause<\/strong>irqbalance distributed over nodes. <strong>Solution<\/strong>Fix IRQ affinity, set RPS\/RFS\/XPS node-compliant.<\/li>\n  <li><strong>Symptom<\/strong>OOM in a node, although system RAM is free. <strong>Cause<\/strong>Strict NUMA mask without buffer. <strong>Solution<\/strong>Correct capacity or use \u201epreferred\u201c, establish alerts per node.<\/li>\n  <li><strong>Symptom<\/strong>Irregular throughput with NVMe. <strong>Cause<\/strong>Incorrect queue mapping, shared queues cross-node. <strong>Solution<\/strong>: blk-mq\/NVMe queues per node, I\/O threads pinned.<\/li>\n<\/ul>\n\n<h2>Practice checklist<\/h2>\n\n<ul>\n  <li>Record topology: Nodes, cores, RAM, PCIe devices per socket.<\/li>\n  <li>Draw service section: Which paths are <strong>Latency<\/strong>-critical, which batch?<\/li>\n  <li>Set CPU\/memory affinity for each class; note first touch at start.<\/li>\n  <li>Bind IRQ\/Queues close to the node; check RSS\/RPS\/XPS and NVMe queues.<\/li>\n  <li>Monitoring on P95\/P99, remote access, run queue, IRQ distribution.<\/li>\n  <li>Control autobalancing specifically; select THP\/zone_reclaim_mode appropriately.<\/li>\n  <li>Keep vNUMA, vCPU pinning and vRAM binding consistent in VMs\/containers.<\/li>\n  <li>Test iteratively, document, roll back in case of drift and fine-tune.<\/li>\n<\/ul>\n\n<h2>Summary and tuning schedule<\/h2>\n\n<p>It brings the greatest return, <strong>Threads<\/strong> and memory together, shorten I\/O paths and only distribute them carefully. I start with topology analysis, plan services node by node, set CPU and memory affinity, connect network\/storage appropriately and monitor P95\/ P99 values with a focus on <strong>remote<\/strong>-accesses. I then tweak pool sizes, IRQ masks and policies until latency peaks subside and throughput increases. I check the placement of VMs and containers separately because the hypervisor has a lot of influence and <strong>Boundaries<\/strong> work differently. If you repeat and document this process, you will get measurably more performance out of Server NUMA Locality and CPU-Memory Affinity - often cheaper than upgrading additional hardware in euros.<\/p>","protected":false},"excerpt":{"rendered":"<p>Learn how Server NUMA Locality and CPU-Memory Affinity optimize your hosting performance. The guide shows practical performance tuning for modern servers.<\/p>","protected":false},"author":1,"featured_media":19858,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-19865","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-server_vm"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"50","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"Server NUMA","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"19858","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/19865","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/comments?post=19865"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/19865\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media\/19858"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media?parent=19865"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/categories?post=19865"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/tags?post=19865"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}