Can you check your .cfg?? I suspect that the following are likely still at the default:
allocate max shared memory = 1
dynamic allocation on demand = DEFAULT
session tempdb log cache size = 32768
The first one might be part of the issue - then I would be checking the values of:
total logical memory
total physical memory
via sp_configure (they are not in the config file) and looking at some of the caches.
However, while you are having a ton of minor page faults per second, that may not be the big limiting factor on throughput. I noted that you have a whopping large amount of inserts into APL heap tables - which typically signals tempdb #temp tables to me....but then I noted:
ULC Flushes to Xact Log per sec
------------------------- ------------
Any Logging Mode DMLs
by End Transaction 2206.1
by Change of Database 0.1
by Unpin 0.0
by Log markers 231.3
Fully Logged DMLs
by Full ULC 374.4
by Single Log Record 0.1
Minimally Logged DMLs
by Full ULC 0.0
by Single Log Record 0.0
by Start of Sub-Command 0.0
by End of Sub-Command 0.0
------------------------- ------------
Total ULC Flushes 2935.0
ULC Flushes Skipped per sec
------------------------- ------------
Fully Logged DMLs
by ULC Discards 1933.8
Minimally Logged DMLs
by ULC Discards 0.0
------------------------- ------------
Total ULC Flushes Skips 1933.8
ULC Log Records per sec
------------------------- ------------
Fully Logged DMLs 167881.3
Minimally Logged DMLs 0.0
------------------------- ------------
Total ULC Log Records 167881.3
which sort of suggests you are not doing any minimally logged operations - but only fully logged ops - including in tempdb.....and that may the cause of the 80 page splits per second as updates to #temp tables could drive not only logged info in #tempdb, but also result in page splits (as well as the page shrinkages also noted). As a result, with the default 'session tempdb log cache size' - you may be actually hitting the tempdb log semaphore (and disk) a lot more often than necessary (and it may be one of the sources of log semaphore contention also reported). A fast way to check is to query monOpenDatabases and see where the AppendLogRequests and AppendLogWaits show up. Another thought about tempdb is that logged DML (insert/update/deletes) can not use the large IO pool - only select/into......your 128KB pool is almost never used...and when it is, I suspect it is to do a large IO scan of tables that were flushed from cache (cache misses in 16KB pool) - you might want to either increase the tempdb cache size slightly - or reallocate memory from both the 32K and 128K pool back to the 16K pool - unfortunately, we don't have sizing info - so can't tell you how much. The sp_sysmon is stating that you only used 5K pages in the 128K pool and that it was 12% of the total (so likely 60K pages in 128K pool) - so you could easily shrink it by 50% or 75%. The 32K pool is showing 100% use - but that is typical for log caches - you likely don't need 50K pages there either - probably less than half that - tran log reads are only problematic when doing large txns, checkpoints or dumps - the last two shouldn't apply - and definitely make the tempdb cache a 'relaxed' cache strategy cache.
Also, the biggest amount of wait time is on incoming network IO - although it is <0.1ms per wait. Assuming the connections for this benchmark are constantly busy, I would then wonder if the other parts of non-execution (e.g. parse, compile and optimization time) are factors here as well. However, you also ran sp_sysmon with 'clear' instead of the default 'noclear' - which hits a lot of the same counters as some of the MDA tables - consequently some of the MDA data is suspect. You really should run sp_sysmon with 'noclear' (or the default) . You do have some proc calls (3000/sec)....which mirrors the packets/sec and a few other things - so am wondering if the client/driver is making a ton of proc calls via language instead of RPC.....however, this is minor compared to the tempdb tuning as well as other aspects that may be much larger players (latch contention, etc.)