According to Mark Russinovich's Windows Internals 5th Edition, Windows uses (small) page sizes of 4 KB on both x86 and x64 architectures to manage memory. Even though I can't find a reason for this, intuitively I'd think SQL Server would use the same size for its own pages but instead it uses page sizes of 8 KB.
I've researched through the documentation and blog posts, but I was unable to find an explanation for this behavior. All I was able to find was that it is the way it is.
I'm definitely not arguing that this is good or bad (and I'm in no position to do so, anyway), I'm just curious and would like to learn the motivation that culminated in this decision.
What is the technical reason for choosing a page size of 8 KB for SQL Server? Why is it a good page size? Or maybe it's just an inheritance from its Sybase lineage?
How does this decision affect SQL Server's performance (meaning how does it interact with the system's memory and disk internally)?
My second thought would be something related to the storage subsystem, but I'm still not sure. (NTFS has a default cluster size of 4KB)
No, it has a cluster size that is configurable and any sql server DBA with a grain of salt has put it to 64kb for the database file partitions.
No, it HAD a 4kb size then moved to 8kb to reduce overhead. They also are managed in extends of 64kgb (8 pages of 8 kb) which are always read and written at the same time. This means that a 64kb NTFS clsuter size for SQL Server is perfect ;)
At the end it is about aligning with aprtitions AND reducing overhead and that is where the sweet spot was assumed to be.