Ein ganzes Netzwerk von Websites wurde auf einmal langsam, und kein einziger Server war ausgelastet.

Ein Netzwerk von Stellenportalen wurde zur selben Zeit weich. Nicht eine Seite, nicht eine Website: alle, zusammen, die Art farmweiter Nebel, die einen Betreiber annehmen lässt, die Server ertrinken und es sei Zeit, größere zu kaufen. Diese Annahme ist teuer, sie ist verbreitet, und in diesem Fall war sie falsch. Jede Maschine in der Farm langweilte sich. Die ganze Farm wartete auf die Datenbank, und die Datenbank wartete auf eine einzige Abfrage.

Jede Ebene war im Leerlauf, außer einer

Bei einer farmweiten Verlangsamung lesen Sie vor allem anderen die Auslastung jeder Ebene und sehen nach, welche tatsächlich am Anschlag ist. Die Load Balancer drehten Däumchen. Die Webserver langweilten sich. Nichts im Request-Pfad arbeitete hart genug, um eine langsame Website zu erklären.

Das ist das Zeichen, das die Kapazitätsdiskussion beendet, bevor sie beginnt. Wenn jede Ebene außer der Datenbank im Leerlauf ist, kauft Ihnen ein größerer Webserver eine schnellere Maschine im Leerlauf. Der Engpass war nie die Rechenleistung, und keine Hardwarebestellung hätte das behoben.

Die teure Antwort war, mehr Maschinen zu kaufen

Mehr Hardware hätte die Verschwendung skaliert, nicht beseitigt. Der einzige ehrliche nächste Schritt war herauszufinden, womit die Datenbank ihre Zeit tatsächlich verbrachte.

Wir haben die Abfragehistorie nach Fingerabdruck aggregiert

Eine Anwendung schreibt dieselbe Abfrage selten zweimal gleich. Dieselbe Abfrage taucht auf mehrere verschiedene Arten parametrisiert auf, sodass das Zählen des rohen Abfragetexts den Übeltäter im Rauschen versteckt. Die Lösung ist, nach einem Fingerabdruck zu aggregieren, der diese Inkonsistenz überlebt, und dann jedes Statement nach seinem Anteil an der gesamten Datenbankzeit zu ordnen. Wir haben das über die vollständige Abfragehistorie laufen lassen.

-- reconstructed, de-identified rendering of cleared facts. not a real capture.
-- full query history, grouped by query_hash
-- (a fingerprint that survives inconsistent parameterisation)
SELECT TOP 5
  query_hash,
  SUM(execution_count)                AS calls,
  SUM(total_logical_reads)            AS pages_read,
  SUM(total_elapsed_time) * 100.0
    / SUM(SUM(total_elapsed_time)) OVER () AS pct_of_db_time
FROM   sys.dm_exec_query_stats
GROUP  BY query_hash
ORDER  BY pct_of_db_time DESC;

Eine Zeile stach heraus: mehr als die Hälfte von allem, was die Datenbank tat, für ein einziges Statement aufgewendet. Die Methode ist absichtlich langweilig, sie rät nicht, und sie ist jedes Mal dieselbe.

Eine Abfrage war mehr als die Hälfte der Datenbank

Das Statement, das herausfiel, ist von der Sorte, die Sie nie ein zweites Mal ansehen würden. Eine Städteabfrage, zwei Spalten, ein Filter.

-- reconstructed, de-identified. table/column names renamed from the real schema.
SELECT CityID, CityName
FROM   Cities
WHERE  RoutingPath = @p;

-- Execution plan: Clustered Index Scan (a full scan)
--   Returns:          ONE row
--   Filtered column:  RoutingPath --> no index

Die Spalte, nach der sie filterte, hatte keinen Index. Also scannte jeder Aufruf die ganze Tabelle, um eine einzige Zeile zurückzugeben. Für sich allein ist das ein kleiner Preis. Wiederholt bei jedem Seitenaufruf im ganzen Netzwerk wurde es zum größten Posten, den die Datenbank hatte.

Eine Antwort aus einer Zeile sollte ein paar Seiten lesen, nicht die ganze Tabelle

“Eine Antwort aus einer Zeile sollte zwei oder drei Seiten lesen, nicht Hunderte.”

Dieser Satz ist die ganze Diagnose, komprimiert auf etwas, das Sie der Person sagen können, der der Code gehört. Nichts anderes lässt eine Abfrage mit einer Ergebniszeile so viel lesen. Keine langsame Platte, keine ausgelastete CPU, keine schlechte Nacht. Eine Antwort aus einer Zeile, die die ganze Tabelle liest, ist ein Full Scan, und ein Full Scan auf einer gefilterten Spalte ist eine unverwechselbare Signatur: Die Spalte braucht einen Index. Wir mussten nicht über Hardware streiten, wir haben einfach die Reads gezeigt.

Ein Online-Index, vom Scan zum Seek

-- reconstructed, de-identified. index name illustrative, on the renamed identifiers.
-- Index the column in the WHERE clause; cover the two columns it returns
CREATE NONCLUSTERED INDEX IX_Cities_RoutingPath
  ON Cities (RoutingPath)
  INCLUDE (CityID, CityName)
  WITH (ONLINE = ON);   -- applied without interrupting the site

-- New execution plan: Index Seek

Ein Index, auf der einen Spalte, nach der die Anwendung tatsächlich filterte. Er wurde online eingespielt, ohne Unterbrechung der Websites, und die Abfrage, die die Datenbank beherrscht hatte, wurde zu einer der günstigsten Dinge, die sie tat.

Der Ingenieur des Kunden ergänzte die Diagnose

Das Beste an dieser Zusammenarbeit war nicht unser Index. Es war das, was geschah, als der eigene Datenbankingenieur des Kunden dazukam und die Diagnose ergänzte: Er brachte ein Reader/Writer-Blocking-Muster von seiner Seite des Systems mit. Wir haben seine Lösung mit unserer zusammengeführt, und beide gingen gemeinsam rein.

“Der Ingenieur des Kunden verließ das Gespräch als Mitstreiter.”

Das ist der Unterschied zwischen einem Support-Ticket und einer Diagnose. Wenn der Befund wahr ist und Sie die Belege zeigen, hören beide Seiten auf, Positionen zu verteidigen, und beginnen, die Plattform gemeinsam zu verbessern.

Wenn jede Ebene im Leerlauf ist, außer einer, hören Sie auf, auf die Kapazität zu schauen

Die Lektion ist kurz, und sie ist das Gegenteil des Reflexes. Farmweite Langsamkeit bei Maschinen im Leerlauf ist kein Kapazitätsproblem, sondern eine Softwarefrage im Kapazitätskostüm. Das prüfen Sie, bevor Sie eine Hardwarebestellung unterschreiben.

Die ganze Zeit über blieb die Maschine ruhig. Die Load Balancer drehten Däumchen, die Webserver saßen gelangweilt herum, und die Lösung war ein Index auf der Spalte, nach der die Anwendung filterte. Der Datenbankserver war gesund. Ein Statement in ihm brauchte einen Index.

Der Instinkt bei einer langsamen Farm ist, sich freizukaufen. Die ehrliche Antwort ist fast immer günstiger: Lesen Sie jede Ebene, finden Sie die, die am Anschlag ist, und lesen Sie ihre Abfragen.