dotyczy wersji: dowolnej; autor: Paweł Jawień
Wydajność Webcon BPS jest nierozerwalnie związana z wydajnością MS SQL na którym pracuje baza danych BPS.
Gdy już przezwyciężymy niedobory pamięci RAM, zoptymalizujemy przestrzeń dyskową dla operacyjnej bazy danych, wykluczymy obciążenie procesorów, wprowadzimy odpowiedni maintance plan dla bazy danych, wydaje się, że już nic więcej nie można zrobić, wówczas z reguły przypomniamy sobie o optymalizacji bazy tempdb (a producent, zaleca, żeby od tego zacząć).
Poniżej przytoczę w oryginale zalecenia Microsoft przy optymalizacji wydajności systemu Sharepoint
TEMPDB is one of the important systems DB regarding the health of the SharePoint.
In SharePoint almost every action/request is generating work in the TEMPDB.
Recommendation for TEMPDB performance:
- Create the TEMPDB database on the fastest storage available (SSD is a great option that would benefit in many ways).
(In cluster 2012 TEMPDB can be on local disk resource (local SSD) as long as it exists on all nodes); always separate the user DB files from the TempDB files. - Pre-allocate space for your TEMPDB files by setting the Initial File size to a larger value so it can accommodate the typical workload in your environment, you can go by a rule of thumb that the size should be 25% of the largest content DB.
- Create multiple data files to maximize disk bandwidth and reduces TEMPDB file contention, Make each files the same size; this allows optimal proportional-fill performance.
- Allow your TEMPDB files to grow automatically and monitor the disk free space, set the file growth in fix size and not in percentage.
Dla udowodnienia tej tezy podam przykład z testowej konfiguracji. Testowaliśmy na „czystym” MS Sharepoint 2013 dodawanie do listy sharepointowej 3000 nowych linii.
W pierwszym podejściu baza tempdb znajdowała się na dysku systemowym (czyli tak jak w 70% znanych nam instalacji), w drugim podejściu zastosowaliśmy dla bazy tempbDB wydzielony dysk SSD (naprawdę szybki dysk „serwerowy”).
W przpadku zastosowania dysku SSD, czas testowej operacji był 44 razy mniejszy od czasu tej samej operacji w przypadku gdy baza tempdb znajdowała się na standardowym dysku (szybkim 15000rpm) współdzielonym z systemem operacyjnym. Oczywiście, zdaję sobie sprawę, że było to porównanie dwu skrajnych konfiguracji, ale różnica jest imponująca i wydaje się, że jest o co walczyć.
W realnym życie i realnych budżetach musimy godzić się na kompromisy, jednak warto wówczas spojrzeć na inne zalecenie MS dla rozmieszczenia baz danych na użytek Sharepointa
- For collaboration or update-intensive sites, use the following ranking for storage distribution.
The highest ranked item should be in the fastest drives.
- tempdb data files and transaction logs
- Content database transaction log files
- Search databases, except for the Search administration database
- Content database data files
- In a heavily read-oriented portal site, prioritize data and search over transaction logs as follows.
The highest ranked item should be in the fastest drives.
- tempdb data files and transaction logs
- Content database data files
- Search databases, except for the Search administration database
- Content database transaction log files
Jak widać niezależnie od sposobu wykorzystania serwera Sharepoint, baza tempdb powinna być umieszczana zawsze na najszybszych dyskach.
Jest jeszcze jedno zalecenie dotyczące bazy tempDB: zaleca się utworzenie kilku plików dla bazy tempdb (w zależności od ilości rdzeni procesorów).
Jest kilka teorii, które mówią, że powinno być tyle plików ile rdzeni, lub liczba rdzeni /2, lub liczba rdzenie /4.
Jeżeli nie mamy odpowiedniej liczby dysków twardych, tak, aby każdy z plików bazy danych tempdb znajdował się na wydzielonym dysku, radzę darować sobie podział bazy na wiele plików i pozostać z jednym plikiem bazy tempdb, za to umieszczonym na dedykowanym, najszybszym dysku twardym.
W nowo wydanej wersji serwera SQL 2016 defaultowa instalacja proponuje utworzenie 4 plików dla bazy tempDB.
