Professional Documents
Culture Documents
Contents
Disclaimer................................................................................................................................................ 3
Overview ................................................................................................................................................. 3
High Level Considerations ....................................................................................................................... 3
Site Database ...................................................................................................................................... 3
Impact of failure .............................................................................................................................. 4
Monitoring Database .......................................................................................................................... 4
Impact of failure .............................................................................................................................. 4
Configuration Logging Database ......................................................................................................... 4
Impact of failure .............................................................................................................................. 5
Temporary Database........................................................................................................................... 5
Read-Committed Snapshot Isolation .................................................................................................. 5
Sizing the Databases ............................................................................................................................... 5
Site Database ...................................................................................................................................... 6
Monitoring Database .......................................................................................................................... 6
Maximum retention periods ........................................................................................................... 6
Estimates with 1 connection and 1 session per user with a 5 day working week .......................... 6
Estimates with 2 connections and 1 session per user with a 5 day working week ........................ 7
Configuration Logging Database ......................................................................................................... 7
Database Activity during logon of 100k HSD Sessions ............................................................................ 7
Transaction Log Growth ...................................................................................................................... 8
Site Database .................................................................................................................................. 8
Monitoring Database ...................................................................................................................... 8
Transactions per second ..................................................................................................................... 8
Site Database .................................................................................................................................. 8
Monitoring Database ...................................................................................................................... 9
CPU usage ........................................................................................................................................... 9
Primary Replica ............................................................................................................................... 9
Secondary Replicas ....................................................................................................................... 10
Temporary Database usage .............................................................................................................. 10
TempDB Sizing................................................................................................................................... 10
Overview
A typical XenDesktop 7 deployment consists of three databases, as follows:
Site Configuration Database
o Stores the current configuration and state of the XenDesktop deployment
Monitoring Database
o Stores historical data for display within Director
Configuration Logging Database
o Tracks configuration changes made to XenDesktop deployment
By default, the Configuration Logging and Monitoring databases (the secondary databases) are
located on the same server as the Site Configuration Database. Initially, all three databases have the
same name. Citrix recommends that you change the location of the secondary databases after you
create a Site.
A typical deployment also makes use of the Temporary Database, TempDB, provided by SQL Server.
This document provides information about each database, and highlights the major considerations
to take into account when sizing databases to support XenDesktop 7.
Note: All numbers provided are estimates. Variations between deployments are to be expected.
Differences in sizing between Hosted Shared Desktops (HSD) and Virtual Desktop Infrastructure (VDI)
are also noted in this document. Mixed environments will need to combine the estimates from the
two desktop types to generate an estimate of the overall database size.
Impact of failure
An outage of the Site Database renders the system unable to broker sessions for users. Existing
connections are maintained, but new connections are not possible.
Monitoring Database
The Monitoring Database contains historical information about the site. This information is used by
Director to display historical information.
Impact of failure
An outage of the Monitoring Database prevents data being collected for the Site, meaning that data
is not visible within Director.
Impact of failure
The impact of an outage of the Configuration Logging database depends on the Site configuration, as
follows:
If the Site does not allow changes when the Configuration Logging Database is unavailable, it
is not possible to reconfigure the XenDesktop deployment.
If the Site does allow changes when the Configuration Logging Database is unavailable,
untracked configuration changes may be made to the XenDesktop deployment.
Temporary Database
The Temporary Database is a system-wide database provided by SQL Server. It is used as a version
store for Read-Committed Snapshot Isolation. XenDesktop 7 uses this SQL Server feature to reduce
lock contention in the XenDesktop databases.
The size of the version store depends on the number of active transactions. In general, however, it is
no more than a few MBs.
The performance of TempDB does impact the performance of XenDesktop brokering, as any
transactions that generate new data require TempDB space. XenDesktop, however, tends to have
short-lived transactions, which helps keep the version store size small.
The Temporary Database is also used when queries generate large intermediate result sets.
http://technet.microsoft.com/en-us/library/ms175527(v=sql.105).aspx
The main area of contention centers on the number of files to use. Older versions of SQL Server,
such as SQL Server 2000, require more files than newer versions. For more information on the
number of files to use, see:
http://www.sqlskills.com/blogs/paul/a-sql-server-dba-myth-a-day-1230-tempdb-should-always-
have-one-data-file-per-processor-core/
A session is any desktop or application running for a period of time that may be disconnected and
reconnected to.
Site Database
The maximum size of the Site Database is based on the number of VDAs and active sessions, as
follows:
Each published application adds ~110KB to the database to store each unique icon.
Monitoring Database
Of the three databases, the Monitoring Database is expected to grow to the largest over time.
Below are estimates for the size of the database at a number of data points; this data is an estimate
based on data seen when scale testing XenDesktop. The estimates are believed to be realistic.
Customers who maintain their database, however, may find their database is smaller than the
estimates.
After data is older than the configured retention period it is removed from the database.
Estimates with 1 connection and 1 session per user with a 5 day working week
Users Type 1 week (MB) 1 Month (MB) 3 Months (MB) 1 Year (MB)
1,000 HSD 20 70 230 900
10,000 HSD 160 600 1,950 7,700
Estimates with 2 connections and 1 session per user with a 5 day working week
Users Type 1 week (MB) 1 Month (MB) 3 Months (MB) 1 Year (MB)
1,000 HSD 30 100 330 1,300
10,000 HSD 240 925 3,000 12,000
100,000 HSD 2,400 9,200 30,000 119,000
1,000 VDI 25 85 280 1,100
10,000 VDI 200 750 2,500 9,800
40,000 VDI 800 3,000 9,700 38,600
Note that HSDs generate more data over time due to the logging of load balancing information, but
are initially a similar size to VDI desktops.
Activities that have an impact on sessions or users are logged and include, for example, session
logoff and reset. Passive activities, such as listing a user’s sessions, are not.
The mechanism used for deploying desktops also impacts the size of the data being logged.
In HSD environments that are not using MCS, database size tends to be between 30 and 40MB.
For MCS environments, database size can easily exceed 200MB due to the logging of all VM build
data.
Details for server configurations are provided at the end of this document.
Site Database
When the system is idle the transaction log grows by 3.5MB an hour. This is a combination of VDA
and Broker Service heartbeats.
Log growth is linear over the time period being measured. This data suggests that, per user logon,
the transaction Log grows by ~20KB. Per user logoff the transaction log grows by ~12KB.
Monitoring Database
When the system is idle the transaction log grows by 30.5MB an hour. This is a combination of
consolidation stored procedures and HSD VDA load index updates.
The log growth is linear over the time period being measured. This data suggests that per user logon
the transaction Log grows by ~7KB. Per user logoff the transaction log grows by ~2KB.
Site Database
When the system is idle, there are ~5 transactions/sec of which ~1 Write Transaction/sec maintains
VDA and Broker heartbeats.
Note: These numbers are estimates taken from the time periods given. Exact load varies depending
on the number of concurrent launches per second.
Monitoring Database
When the system is idle, consolidation stored procedures run once a minute, and generate
transactions. The level of transactions, however, is small. In general, there are 2-3 transactions and 1
write transaction for each consolidation stored procedure, and 3 consolidation stored procedures
are run. During active periods the overhead increases as more work is carried out.
Note: These numbers are estimates taken from the time periods given.
Logon Logoff
Test Transactions Per Write Transactions Transactions Per Write Transactions
Sec per Sec Sec Per Sec
100k over 1
4 2 4 2
hour
100k over 2
4 2 3.5 2
hours
CPU usage
All SQL servers used for this testing were dual hex-core servers with hyper-threading enabled. The
exact hardware specifications are provided at the end of this document.
The servers were known to be over-sized for the load being run. This allowed us to identify the
limitations and maximums placed on the hardware. It is expected that the SQL CPU load could
actually have been handled by an SQL Server with a single quad-core, rather than a dual hex-core
system.
During tests the System CPU was monitored using the performance monitor counter
Processor -- % Processor Time -- _Total.
Primary Replica
While idle CPU ran at 0-2% of the available CPU. The consolidation stored procedures caused spikes
every minute for ~1s to 8-10% of the system CPU. This is expected to scale based on the amount of
data being processed.
During the logon of 100K users in 1 hour, CPU jumped to 7% and increased linearly to 11% as more
sessions and users were present in the environment. Note that the consolidation stored procedures
spikes added ~7% to the total CPU, causing the spikes to reach 18% of the CPU.
During logoff CPU ran at ~3.5%, with 7% extra CPU for the consolidation stored procedures. Overall
this suggests that <20% of a dual hex-core was needed to sustain the logon and logoff rate.
Given the workload, it is believed that this is a heavy stress test, and that a single quad-core SQL
server would be adequate for XenDesktop deployments.
Secondary Replicas
Secondary replicas were found to configure ~2% CPU during logon and ~1.5% during logoff. This is to
be expected as, for the most part, replicas are storing data from the primary on their disks, and only
the synchronous replica is involved with transactions, as the principal replica does not commit a
transaction until the secondary acknowledges it.
Based on recommendations for HA hardware to match the primary replica, this load would be
handled very easily by a similarly specified server.
TempDB Sizing
In this SQL configuration TempDB was configured to have 8 database files, each of a fixed 5GB in
size. This allows for better concurrent use of TempDB but also provides plenty of space and does not
trigger any autogrow events. Based on the data captured it was oversized for this deployment. There
was, however, plenty of disk space available.
It also keeps within general guidance of the number of TempDB database files being between a
quarter and a half of the number of CPUS available, but not exceeding 8 without knowing there is
actual contention.
Note that only one TempDB log file is used, as SQL Server does not benefit from multiple log files.
Version Store
TempDB contains a version store for row versions related to the Read Committed Snapshot Isolation
used by XenDesktop databases.
During a 100k logon over 1 hour, the version store size stayed in the range of 10MB to 30MB, with a
saw tooth effect as versions were created and then cleaned up. During logoff, the range was 10MB
to 21MB. When idle, the version store size ranged from 1 to 4MB.
The Version Generation Rate was in the 250 to 500KB/s range during logon; 150 to 400KB/s during
logoff, and 0 to 250KB/s when idle.
Disk I/O
During the logon tests the disk I/O was measured with the following performance counters:
PhysicalDisk – Disk Read Bytes/sec
PhysicalDisk – Disk Write Bytes/sec
PhysicalDisk – Disk Reads/sec
PhysicalDisk – Disk Writes/sec
Read I/O was found to be minimal, as the SQL server was able to hold all data in memory, causing
very little read activity on the system.
Due to the layout of the databases and the storage system the volumes were split, with one volume
holding all the data files, and a second volume holding all the transaction log files.
The data shows a pattern that is hard to place into a table. In general the transaction log had a write
bytes/sec of ~800KB/s for the 1 hour test, and 400KB/s for the 2 hour test. Once a minute, when the
consolidation stored procedures run, the transaction log showed spikes to ~30MB/s.
Analysis of the consolidation stored procedures shows that sometimes the statistics make the query
plan sub-optimal, and a temporary table spills into TempDB. This triggers writes to the transaction
log for TempDB.
This data transfer translates to a steady state of ~300 write IOPs for the 1 hour test, and ~200 write
IOPs for the 2 hour test. The spikes for the consolidation stored procedures add another 2-300 Write
IOPs while running. Note that in a large environment the consolidation stored procedures run for
less than a second.
When each database is checkpointed, data is synced from the in-memory tables to data files on the
data volume.
These checkpoints are very short periods of activity, generally less than 1s.
During logon the checkpoints consumed ~500 write IOPs and 6-7MB/s. During logoff the checkpoints
consumed ~7MB/s and 200 or 700 IOPs. This variance is because the Site and Monitoring databases
have different amounts of data to checkpoint.
Database Maintenance
Database maintenance in a large deployment is important. If the database is not properly
maintained database outages may occur due to lack of database space, for example, if the
transaction log is set to autogrow and fills up the disk, or the transaction log is a fixed size and
becomes full.
By running in Full transaction logging mode the transaction log continues to grow until a database or
transaction log backup is taken.
This can cause issues if the transaction log files are not monitored as, by default, SQL Server
configures the log files to autogrow. This causes 2 issues:
1. The transaction log files can consume a lot of disk space
2. Every time the transaction log grows it stalls all transactions until the log space has been
zeroed.
Citrix recommends that the log files are backed up regularly. This can be done with scheduled jobs or
maintenance plans.
Alternatively, use the SQL Server Agent to monitor when the log used size passes a threshold and
run a backup job.
In scale testing a fixed size log of 4GB was used, and an alert was set to back up the log to another
file when the log file reached 80% full. This stopped the log growing and consuming all the disk
space, and also stopped it zeroing the disk space and stalling the database.
The backup of the log file was found to have minimal impact on a running XenDesktop environment,
there’s a marginal increase in the brokering times, but not something we believe to be significant.
Index maintenance
As more data is entered into the database some of the indexes start to become less full, that is fewer
records are stored in each SQL page. A SQL Page is 8KB in size. This causes the database to increase
its storage needs, both in memory and on disk.
By maintaining the indexes the page fullness can be increased, which reduces the memory
requirements of the database.
This recommendation avoids any performance impact of rebuilding any large indexes during day-to-
day operations, especially for a large Monitoring Database.
Microsoft recommends that indexes are rebuilt if they are greater than 30% fragmented, and
reorganized if less than 30%.
After reorganizing indexes, statistics should also be updated. This is particularly important as the
database grows; otherwise some statistics may be poor and SQL may generate sub-optimal SQL
query plans.
In terms of space saved, the Microsoft script below was run against a 1.2GB Monitoring Database. It
improved the page filling and freed up 300MB of space.
http://gallery.technet.microsoft.com/scriptcenter/6f8cde49-5c52-4abd-9820-f1d270ddea61
By changing the “USE SUSDB” this script can also be run against XenDesktop databases.
This script follows Microsoft best practice of rebuilding indexes over 30% fragmented, and
reorganizing those under 30%. It then updates statistics for the database.
Ola Hallengren
More advanced scripts are also available from:
http://ola.hallengren.com/
These scripts are well regarded in the SQL Server community. Specifically, the Index scripts available
from:
http://ola.hallengren.com/sql-server-index-and-statistics-maintenance.html
These scripts can be used for finer control over the levels to reorganize or rebuild indexes.
System Specification:
2 hex-core Intel Xeon CPU E5-2630 running at 2.30GHz with hyper-threading enabled
Software:
Windows Server 2012 standard edition, with current windows updates at time of testing
(August 2013)
SQL Server Enterprise 2012 SP1 with Cumulative Update 5
Configuration changes
SQL Server was configured to use a maximum of 61440MB
Database containment was enabled on all SQL Instances
SQL Server Agent service was configured to automatically start
Note: While these servers are relatively old, the workload on the HSD servers is low, as the Session
Simulation is mainly focused on placing load on the Delivery Controllers, rather than the HSD
servers.
System Specification:
2 quad-core Intel Xeon L5320 running at 1.86Ghz, not hyper-thread capable
16GB ECC RAM
Software:
Windows Server 2012 Standard edition, with current Windows updates at time of testing
(August 2013)
Citrix XenDesktop 7.0