I'm using a PG13 server as a feature DB. There is no else job on the server but this PG instance and a GPU based machine learning process. There is no online transaction, and the data lossing or incorrect are not trouble, I just need it run faster. Few days ago, with a lot of gentlemen's help in my another question , I have corrected some mis-configurations of my PG server. But the throughput of the PG server delivering data still can **NOT** satisfy the reuqiement of the ML process. I need the PG server to produce data as fast as possible, or in other word, to load data from disk more aggressively. There are two physical CPU(as two numa nodes), and each of them has 128 real cores(I disabled Super Threads in BIOS setup), 128GB memory(I splited 64GB dedicated for PG). Since whole of CPU1 has been assigned dedicated for PG use, PG is configed with 128 parallel workers. The result is **NOT** as my expecting, the throughput still lower. The bandwidth of the SSD RAID is 10GB/s, but the actual reading/writing rate of PG is 100~200MB/s, only like a SATA hard disk. I don't believe it has only so poor performance, because I did some experiments/observing as fowllowing: 1. Directly read/write raw file by means of dd command, and count the io rate. I even writed a C++ program that starts multi-threads directly dump/load data to/from files on the RAID. The io rate can easily continuously exceed 10GB/s viewed by iotop command. So I think that the configurations of the hardware, driver soft and the OS(Debian12) should be ok; 2. By watching the output of top/numastat, I found that most PG workers mearly use very less of CPU/mem resources, even though there are 128 hungry clients awaiting data. If they(PG workers) are waiting for io, the RAID should be very busy. But I neven observed the io rate exceed 300MB/s when PG working. If they(PG workers) are doing some DB operations such as sorting/filtering/aggregating, should I see a higher usage percentage of CPU1? Neither io rate nor CPU usage are high, what are they doing when 128 parallel clients are running and constantly doing a simple query(with different filter arguments)? 3. I have tried to limit all processes of PG to run at a same numa node by means of numactl --cpunodebind 1 --membind 1 -- ..., in order to prevent "CPU cache ping-pong" occursing between numa nodes. I also limited the client processes run only at CPU0, to prevent them from contention CPU1. But the throughput didn't improve. 4. I tried different values of option effective_io_concurrency in postgresql.conf, such as 1, 256, 512, even 1000, but the results are similar. How to make my PG server really busy up? Forgive my ugly English, I hope I expressed things correctly. Thanks!

We are using PostgreSql-13 as our core server, and encountered a performance bottleneck. The hardware includes 2 CPUs(AMD EPYC9754 with 128 core 256 threads of each), 128GB memory, hardware RAID0 includes 2 * 4T SSD(Samsung990Pro). I think that the PG server fails to use the full potential of the hardware. Before I asked this question here, I have done things as following: 1. Check my SQL query(exactly using primary key, with no seq scanning); 2. Confirm my program runs correctly(I even though write the same logic in Python and C++, but both runs slowly); 3. Config my PG server to use HugePage(I configured 80GB HugePage memory in total, and allow PG-server use 64GB as shared_buffers); 4. Increase the memory limits of each PG worker(work_mem, temp_buffers,...); 5. Increase the number of parallel workers(max_worker_processes, max_parallel_workers_per_gather, max_parallel_workers,...); 6. Turn on force_parallel_mode; 7. Decrease the io cost and cpu cost cfg(random_page_cost=1.01, cpu_tuple_cost=0.0025, cpu_index_tuple_cost=0.001,...); 8. Maxiumized default_statistics_target to 1000; 9. Disable replications; 10. Startup 32 or 64 processes parallely connect to the server, and query different rows of a same table with different primary keys. 11. All queries are readonly, and there's **NO** insert/update/DDL operations during testing; What I'm expecting: 1. PG server use at least 50% CPU/memory resource; 2. There is **NO** single process blocking other queries; 3. The total throughput basically increases linearly as the amount of the resource I allocated to PG server(maybe I'm naive?); My testing: 1. The table definition: CREATE TABLE IF NOT EXISTS ob_lots( t_stamp INT8 NOT NULL, trd_sec INT4 NOT NULL, o_level INT2 NOT NULL, i_olots INT4 NOT NULL, f_olots FLOAT4 NULL, CONSTRAINT prk_ob_lots PRIMARY KEY( t_stamp, o_level ) ); 2. The query: SELECT f_olots, t_stamp, trd_sec FROM ob_lots WHERE t_stamp BETWEEN $1 AND $2 ORDER BY t_stamp DESC, o_level DESC LIMIT 4096; 3. Testing program: Start up many instances of my program that randomly query rows of above table parallelly with above query SQL. When the number of the clients was increasing from 2 to 4, or from 4 to 8, or from 8 to 16, we **did** observed that the total throughput was nearly doubled every time. But from 16,32 or higher, the total throughput never changed. 4. SQL explaination: Gather (cost=1000.28..1002.41 rows=1 width=18) (actual time=6.840..9.232 rows=0 loops=1) Workers Planned: 1 Workers Launched: 1 Single Copy: true Buffers: shared hit=8 -> Limit (cost=0.28..2.31 rows=1 width=18) (actual time=0.033..0.033 rows=0 loops=1) Buffers: shared hit=8 -> Index Scan Backward using prk_ob_lots_sc5555 on ob_lots_sc5555 (cost=0.28..2.31 rows=1 width=18) (actual time=0.031..0.031 rows=0 loops=1) Index Cond: ((t_stamp >= 123) AND (t_stamp max_connections = 2048 > > shared_buffers = 64GB > > huge_pages = on > > temp_buffers = 256MB > > max_prepared_transactions = 256 > > work_mem = 256MB > > maintenance_work_mem = 16GB > > autovacuum_work_mem = -1 > > dynamic_shared_memory_type = posix > > effective_io_concurrency = 1000 > > maintenance_io_concurrency = 1000 > > max_worker_processes = 256 > > max_parallel_maintenance_workers = 256 > > max_parallel_workers_per_gather = 256 > > parallel_leader_participation = on > > max_parallel_workers = 256 > > fsync = off > > synchronous_commit = off > > full_page_writes = off > > wal_compression = on > > wal_buffers = -1 > > wal_writer_delay = 10000ms > > wal_writer_flush_after = 1GB > > commit_delay = 100000 > > commit_siblings = 128 > > checkpoint_timeout = 1d > > max_wal_size = 128GB > > min_wal_size = 32GB > > checkpoint_completion_target = 1.0 > > checkpoint_flush_after = 0 > > checkpoint_warning = 0 > > max_wal_senders = 0 > > seq_page_cost = 1.0 > > random_page_cost = 1.01 > > cpu_tuple_cost = 0.0025 > > cpu_index_tuple_cost = 0.001 > > cpu_operator_cost = 0.00125 > > effective_cache_size = 64GB > > default_statistics_target = 1000 > > force_parallel_mode = on > > autovacuum = on And the outputs of top and iotop: > top - 16:38:16 up 4:09, 2 users, load average: 14.16, 9.14, 3.97 > > 任务: 1581 total, 2 running, 1573 sleeping, 0 stopped, 6 zombie > > %Cpu(s): 3.5 us, 4.3 sy, 0.0 ni, 92.1 id, 0.0 wa, 0.0 hi, 0.1 si, 0.0 st > > GiB Mem : 125.6 total, 34.6 free, 82.9 used, 9.1 buff/cache > > GiB Swap: 1.0 total, 1.0 free, 0.0 used. 42.6 avail Mem > > 进程号 USER PR NI VIRT RES SHR SWAP %CPU %MEM TIME+ COMMAND > > 31159 leon 20 0 4654.2m 105.1m 12.5m 0.0m S 152.7 0.1 7:09.93 load > > 3186 postgres 0 -20 66.7g 18.6m 16.2m 0.0m R 99.5 0.0 5:03.16 postgres #it's the master? > > 3192 postgres 0 -20 80.4m 6.8m 3.6m 0.0m S 8.2 0.0 0:24.97 postgres > > 32218 postgres 0 -20 66.7g 13.5m 9.9m 0.0m S 5.8 0.0 0:12.90 postgres > > 31217 postgres 0 -20 66.7g 13.4m 9.9m 0.0m S 5.3 0.0 0:12.74 postgres > > 31234 postgres 0 -20 66.7g 13.5m 9.9m 0.0m S 5.3 0.0 0:12.74 postgres > > ( many many postgres process... ) > Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s > > Current DISK READ: 0.00 B/s | Current DISK WRITE: 0.00 B/s > > TID PRIO USER DISK READ DISK WRITE> COMMAND > > 1 be/4 root 0.00 B/s 0.00 B/s init > > 2 be/4 root 0.00 B/s 0.00 B/s [kthreadd] > > 3 be/0 root 0.00 B/s 0.00 B/s [rcu_gp] > > 4 be/0 root 0.00 B/s 0.00 B/s [rcu_par_gp] > > 5 be/0 root 0.00 B/s 0.00 B/s [slub_flushwq]

Link: https://learn.microsoft.com/en-US/sql/database-engine/configure-windows/configure-the-max-degree-of-parallelism-server-configuration-option?view=sql-server-ver15#Recommendations I understand the basic concept of max dop and cost threshold. I am reviewing 3 SQL servers (**virtualized**, not physical machines) with the following combinations of socket and virtual processor: 1. 1 socket 2 virtual processors 2. 12 sockets 24 virtual processors 3. 24 sockets 24 virtual processors The max dop is 0 and cost threshold is 5. I am reading the recommendation from the above link and they have used terms like logical processor, NUMA node. Where as when I open the task manager I can see number of sockets and virtual processors. > Starting with SQL Server 2016 (13.x), during service startup if the > Database Engine detects more than eight physical cores per NUMA node > or socket at startup, soft-NUMA nodes are created automatically by > default. I understand that Soft NUMA means that - it creates software based NUMA so that cores can be shared with multiple sockets. Questions: 1. Does NUMA node and socket mean the same thing? 2. In my examples, does the server configuration (see table from the above link) classify as single NUMA node or multiple NUMA nodes? If NUMA and socket is the same thing then I assume answer is multiple NUMA nodes? 3. Does physical core also mean virtual processor?

Regarding the query below which I run on a physical server with SQL Server 2019: SELECT memory_node_id, SUM(pages_kb) / 1024.0/1024 AS TotalMemoryGB FROM sys.dm_os_memory_clerks GROUP BY memory_node_id ORDER BY memory_node_id; for memory_node_id = 0 it shows more memory than physically available on the NUMA node. How can that be?

We have clustered servers, each of which has 32 CPU cores and 512 GB memory. The cluster is home to 7 instances of SQL Server 2012 **Standard Edition.** With Standard Edition allowing a maximum of 64 GB assigned to any one instance, I was wondering if we should be changing the NUMA setting to maximize utilization of CPU cores? Specifically, I'm thinking of modifying processor affinity. I have done loads of reading where foreign memory access has an overhead to that of local memory access.

we encountered one mysterious problem. After adding 6 more processors to our database server, from 6 to 12, we are unable to adjust the processor settings on any of the instances. We are now running SQL Server 2019 with 12 processors. The catch is after adding more processors, SQL created another NumaNode group, but with the same name as the previous one - NumaNode0. I assume that's why I'm getting the error below when I try to change the settings. The production environment has 5 instances. Any suggestions on how to fix this easily? Thanks ! **Edit:** Output from sys.dm_os_nodes: Output from sys.dm_os_schedulers: And output from sys.configurations:

Link: https://learn.microsoft.com/en-us/sql/sql-server/editions-and-components-of-sql-server-2016?view=sql-server-2017#RDBMSSP For NUMA Aware Large Page Memory and Buffer Array Allocation the table says No And further below it says: > Standard Edition and SQL Server + CAL-based licensing can restrict how > many processors SQL Server Standard can use, but SQL Server Standard > is NUMA aware. This question is to ask whether SQL standard edition (2016, 2017, 2019) has NUMA support because the table and the above quote show conflicting information. The table for SQL server 2017 and 2019 say No without any quote. So was NUMA supported in 2016 and not supported in 2017 & 2019? Links: https://learn.microsoft.com/en-us/sql/sql-server/editions-and-components-of-sql-server-2019?view=sql-server-2017#RDBMSSP https://learn.microsoft.com/en-us/sql/sql-server/editions-and-components-of-sql-server-2017?view=sql-server-2017#RDBMSSP

### Scenario Let's assume I have a SQL Server with 4 sockets with each 1 NUMA node. Each socket has 4 physical cores. There is 512 GB of memory total so each NUMA node has 128 GB of RAM. A key table is loaded into the first NUMA node. ### Question Let's assume we have a lot of traffic reading from that table. If all physical cores of the socket that owns the NUMA node have 100 percent CPU utilization, does that negatively influence the cost of non-local NUMA access coming from other sockets? Or on the other hand is the cost of non-local NUMA access is irrespective of how busy that socket is? I hope my question makes sense. Please let me know if it doesn't I will try to clarify. ### Background We had a database issue in our production server last week and some of our business processed appeared more impacted than others. We had queries with few logical reads taking more than 1 minute. We looked at overall CPU utilization which was around 60 percent. We did not look at socket specific CPU metrics. I/O metrics were average.

Accidental DB admin here. **Question:** Would you still manually limit max RAM for SQL Server even though the sole purpose of that server is to serve SQL Server database engine only? I have Microsoft Windows 2012 R2 Server, SQL Server 2012 Std, with 32GB RAM. Admin constantly login to the SQL Server to use its console and all. Secondly, how do you check if this Windows server is NUMA enabled?

I have a SQL Server 2022 Enterprise instance in a VMWare VM. We upgraded this instance last week from Standard to Enterprise and I want to now make sure we use the appropriate instance level setting for MAXDOP. The VM has a single NUMA node (NUMA Nodes is grayed out in Task Manager|CPU). The SQL Server log shows this: Soft NUMA is enabled, and the way I understand the output is there are 3 soft NUMA nodes. However, when I query sys.dm_os_memory_nodes I read the output as having 2 NUMA nodes, plus the one dedicated for admin connection (memory_node_id 64). Something further that is throwing me off is the results of this query of sys.dm_os_memory_clerks: Can someone help me to confirm how many nodes I actually have? Are the log output and the results of sys.dm_os_memory_nodes giving me what I want, and I have 2 nodes plus the dedicated admin connection? If that's the case, what is the query from sys.dm_os_memory_clerks telling me? **EDIT:** Here is the output of sys.dm_os_nodes as requested.

We're running two different versions of Postgresql on two separate servers: - Server A: Postgresql 9.3 - Server B: Postgresql 15.3 Server B is way more powerful than server A: - Server A: 1x Intel Xeon E3-1270 3.5GHz, 2x 8GB DDR3, RAID0 - Server B: 2x Intel Xeon Platinum 8260 2.4GHz, 4x 16GB DDR4, RAID1 When we run fast short SELECT queries ( Index Only Scan using foobar_pkey on public.foobar (cost=0.42..8.44 rows=1 width=0) (actual time=0.008..0.008 rows=1 loops=1) Output: 1 Index Cond: (foobar.id = 1) Heap Fetches: 1 Buffers: shared hit=5 Total runtime: 0.017 ms (9 rows) Time: 0.281 ms

Server B:

# EXPLAIN (ANALYZE, BUFFERS, VERBOSE) SELECT 1 AS "a" FROM "foobar" WHERE ("foobar"."id" = 1) LIMIT 1; QUERY PLAN ------------------------------------------------------------------------------------------------------------------------------------------------------------ Limit (cost=0.00..1.11 rows=1 width=4) (actual time=0.019..0.021 rows=1 loops=1) Output: 1 Buffers: shared hit=4 -> Index Only Scan using foobar_pkey on public.foobar (cost=0.00..1.11 rows=1 width=4) (actual time=0.018..0.018 rows=1 loops=1) Output: 1 Index Cond: (foobar.id = 1) Heap Fetches: 0 Buffers: shared hit=4 Planning Time: 0.110 ms Execution Time: 0.045 ms (10 rows) Time: 0.635 ms

RAID1 could add some latency on server B if we were reading from disk, but we've confirmed these queries are hitting the buffer/cache and therefore reading data from memory and not from disk. We've checked the hit rate with the following query:

sql SELECT 'cache hit rate' AS name, sum(heap_blks_hit) / (sum(heap_blks_hit) + sum(heap_blks_read)) AS ratio FROM pg_statio_user_tables; ``` The latency is quite low on both servers, but when you're running a bunch of fast short queries concurrently, on aggregate you see the difference, with server A being 0.1-1.0 seconds faster on average than server B. Server B has 2 CPUs and is using NUMA on Linux. Maybe that's adding some overhead/latency? Transparent Huge Tables is set to 'madvise' on Linux and huge_pages is set to try on Postgresql. Any ideas?

We have a server with 8 CPUS across 2 NUMAs with hyperthreading enabled. Currently Maxdop is set to 8, but actually should be set to 4 as per the Maxdop section of this article: https://support.microsoft.com/en-us/kb/322385 So we need to change it to 4. However my question is what is the impact of having maxdop set to 8? So going parallel across two NUMAS ? The reason I ask is that we just had a strange issue where queries were very slow to return and PLE dropped off rapidly. Even when nothing was running against SQL PLE didn't not improve. CXPACKET wait types went up. Then all of a sudden CXPACKET wait type dropped completely and PLE began to rise and now has returned to normal. Throughout this time small queries were being executed against a database, however it was not the case that one query finished causing the CXPACKET wait type to drop off and PLE to rise again - we don't know what causes that. A possible explanation is the incorrect MAXDOP setting. Can anyone explain to me the impact of parallel executions across NUMA nodes, is it just the same as exhausting worker threads and slower access time when using foreign memory ? Thank you

I'm running SQL Server 2022 RC1 setup on an AWS i3.16xlarge with 2 sockets, 2 NUMA nodes, 32 logical processors per node, 64 logical processors altogether. Setup is recommending MAXDOP 8: But if you click on that link for configuring MAXDOP , the recommendations say: Based on that KB article, MAXDOP should be 16, not 8. Sure, technically 8 is less than 16 - but so is 2, or 4, or 15. Where's the 8 coming from? After SQL Server installation finishes and the service starts up, the log shows that SQL Server is automatically implementing Soft-NUMA with 4 nodes, each with 16 logical processors: So again, that indicates that MAXDOP should be 16. Is this a bug, or did I miss something obvious? Is there another unwritten rule somewhere that setup will stop at MAXDOP 8?

Link: https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/solutions/sql-server-on-vmware-best-practices-guide.pdf > This architecture having ultimate benefits also poses some trade-offs > that needs to be considered and the most important of them—the time to > access data in memory varies depending on local or remote placement of > the corresponding memory cacheline to a CPU core executing the > request, with remote access being up to X29 times slower than local. > > > >29 Depending on the implementation and the processor family, this difference could be up to 3X (Source: pdf , p.6) Here is an example (https://www.sqlskills.com/blogs/jonathan/understanding-non-uniform-memory-accessarchitectures-numa/) of the interconnect: As per above quote - Time to access data in remote memory (via interconnect) is X times slower than local. Had there been no NUMA, and the CPUs were to access memory (from central location), then will it be slower or faster compared to the interconnect access?

I have SSRS and SQL Server running on same physical server (2 NUMA nodes).
How do you configure SQL Server and SSRS to use separate NUMA nodes? I just didn't want SQL Data Engine to potentially consume 100% CPU resources and leave nothing for SSRS.

I just learned some NUMA related knowledge and I want to know: 1. Is NUMA a bad thing for SQL Server? I ask because this Microsoft employee said that: > Basically fewer nodes is better, but there's a limit to how many cores and how much RAM you can put on a single NUMA node. It seems that we use NUMA on SQL Server servers solely because we want huge RAM and more processors, and the hardware vendor created these NUMA nodes for us just because the server is more performant with NUMA architecture. Is this true? 2. Since I don't have a computer with multiple hardware CPU, I can't test NUMA architecture. Is possible to test it on Azure or AWS? What's the approximate cost of using it for 24 hours?

Pretty sure I understand this, but wanted to be sure I do. We have a SQL Server 2016, that is running with 2 NumaNodes, each with 8 vCPUs. The Max Degrees of Parallelism (MAXDOP) is set to 8. This doesn't sound right to me. First question: Is that as bad an idea as I think it is? From my research, I need to tell them to reduce the VM Settings to make this run in a single NUMANode. We seem to be having random periods where queries that were running in 170 ms, are now timing out at 30+ seconds! So, we do a quick look, and it is 5% CPU use, and low disk I/O use, and reasonable network use... Basically, the machine is about idle.. We also looked for queries waiting on locks, and there were none. We are running the queries on the Secondary in a AG Group (a Read Only Query) So, my guess: It has gotten enough load that it switched and ran one the view in question (gets run about 4,000 times per day) on one of the vCPUs in the 2nd NUMANode, and then decided that execution plan should be always run on that node. The result is that all the data it is accessing is cached in the other node's memory, and it needs to fetch it across the inter-node link (remote memory), so it does that, but that ends up being a lot slower (170 times?), and the queries are now all stacking up running more and more of them across this remote link... until it will always timeout because the remote memory is saturated... Is that analysis valid? I would hate to submit this as a solution to why the query suddenly jumps up in time if this is totally not correct. And it will be hard to convince them they will get better performance with 8 CPUs than with 16. Oh, additional evidence to back up my claim: If I select * into #tmp from myView OPTION (MAXDOP 16) then I get a performance change of about -5% to -12% - meaning that it takes longer to run the query than if I just used the 8 vCPUs. However, not massively so. So my question is: Is there any validity to my analysis? Update: A couple other things, I got a lot of the information from: https://codenotary-compliance.medium.com/vmware-vsphere-why-checking-numa-configuration-is-so-important-9764c16a7e73 Secondly, If I do a select * from sys.[dm_os_nodes] Then I get foreign_commited_KB as 5,414,260 or 5 GB, from the information above, that would sound like it is committed out of the other node which (is bad?)

I run query select cpu_count, hyperthread_ratio, softnuma_configuration, softnuma_configuration_desc from sys.dm_os_sys_info and got results, where said, that numa is off: cpu_count hyperthread_ratio softnuma_configuration softnuma_configuration_desc 32 16 0 OFF Then I run another query SELECT name, value, value_in_use, minimum, maximum, [description], is_dynamic, is_advanced FROM sys.configurations WITH (NOLOCK) ORDER BY name OPTION (RECOMPILE); and got result, where said, that auto-numa is not disabled name value value_in_use automatic soft-NUMA disabled 0 0 Where is the right info? In Task Manager I see node0 and node1. We use Microsoft SQL Server 2017 (RTM-GDR) (KB4583456) - 14.0.2037.2 (X64) Nov 2 2020 19:19:59 Copyright (C) 2017 Microsoft Corporation Standard Edition (64-bit) on Windows Server 2016 Standard 10.0 (Build 14393: ) I have this message in the log - does this mean NUMA is being used correctly and that I don't need to do anything else?  Shows 8 cores: 

Querying the dm_os_performance_counters shows that I have **2** NUMA nodes: select * from sys.dm_os_performance_counters where object_name = 'SQLServer:Buffer Node' and counter_name = 'Page life expectancy' Querying the **sys.dm_os_sys_info** shows: Numa node count 4 CPU count 24 Softnumae_configuration 1 Socket_count 24 Cores per socket 1 Where as when I right click on **SQL server properties**, click on Processors it shows 2 NUMA nodes, each with 12 CPUs. **SQL error log**: SQL Server detected 24 sockets with 1 cores per socket and 1 logical processors per socket. 24 total logical processors. Automatic soft-NUMA was enabled because SQL server has detected hardware NUMA nodes with greater than 8 physical cores. So what is the final value of NUMA and CPUs? I am asking because it is recommended to have the MAX DOP configured based on the number of NUMA nodes and the processors per node (https://learn.microsoft.com/en-us/sql/database-engine/configure-windows/configure-the-max-degree-of-parallelism-server-configuration-option?view=sql-server-ver15#Recommendations) . How to decide on the **MAX DOP** when there is discrepancy between processor count reported in **sys.dm_os_sys_info** vs **server properties** vs **SQL error logs**?

> The number of secondary data files depends on the number of (logical) > processors on the machine. As a general rule, if the number of logical > processors is less than or equal to eight, use the same number of data > files as logical processors. If the number of logical processors is > greater than eight, use eight data files. Link: https://learn.microsoft.com/en-us/sql/relational-databases/databases/tempdb-database?view=sql-server-ver15#physical-properties-of-tempdb-in-sql-server In server properties, processors section, I can see there are 2 NUMA nodes with 12 processors each. In the SQL error logs I can see: SQL Server detected 24 sockets with 1 cores per socket and 1 logical processors per socket. 24 total logical processors. Automatic soft-NUMA was enabled because SQL server has detected hardware NUMA nodes with greater than 8 physical cores. So it looks like the computer has got 4 physical processor nodes, with 6 logical processors in each node. In this scenario what is the recommended value of number of tempdb and does it depend on the number of NUMA nodes or number of total logical processors or number of logical processors per NUMA node? I am asking because the previous DBA has set the number of tempdb files to 6 (this is the number of logical processors in a single NUMA node). Whereas I understand based on the above MSDN link that the best practice is to configure the number of tempdb files as 8 or more in increments of 4 (12, 16, 20, 24).