Очень неожиданные тайм-ауты запроса, уменьшенные путем усечения таблицы

Question

У меня есть таблица журнала SQL, в которой хранятся HTTP-запросы:

CREATE TABLE [dbo].[ApiHttpRequests](
[Id] [uniqueidentifier] NOT NULL,
[Environment] [nvarchar](10) NOT NULL,
[ApiRef] [nvarchar](10) NOT NULL,
[StampUtc] [datetime] NOT NULL,
[Host] [nvarchar](255) NOT NULL,
[Verb] [int] NOT NULL,
[Path] [nvarchar](255) NOT NULL,
[Query] [nvarchar](255) NULL,
[ContentLengthHeader] [bigint] NULL,
[AcceptHeader] [nvarchar](255) NULL,
[ContentTypeHeader] [nvarchar](255) NULL,
[UserAgentHeader] [nvarchar](255) NULL,
[OtherHeaders] [nvarchar](max) NULL,
[Body] [nvarchar](max) NULL,
[ResponseStampUtc] [datetime] NULL,
[StatusCode] [int] NULL,
[ResponseContentLengthHeader] [bigint] NULL,
[ResponseContentTypeHeader] [nvarchar](255) NULL,
[OtherResponseHeaders] [nvarchar](max) NULL,
[ResponseBody] [nvarchar](max) NULL,
[RowVersion] [timestamp] NOT NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO

Идентификаторы действительно являются GUID, но они автоинкрементны и генерируются в приложении сервера.

Записи вставляются вскажем 3-5 в секунду, когда запрос начинается, и обновляется снова, когда он обрабатывается.Когда говорят 4 000 000 записей, статистика хранения таблицы составляет 16 ГБ общего пространства, 16 ГБ используемого пространства, 7 ГБ пространства данных (я думаю, примерно ~ 4 КБ на запись).

Индексы в таблице:

1. Id, кластерный первичный ключ (используется для ОБНОВЛЕНИЯ)
2. Environment (на самом деле это может быть не использовано)
3. Environment, StampUtc - используется для очистки старых записей

Каждую минуту выполняется следующее:

DELETE FROM ApiHttpRequests WHERE Environment=@p0 AND StampUtc<=@p1

Обычно этот запрос занимает ~ 10 мс.

Однако через некоторое время (около отметки 2,3 мили сегодня), он внезапно и мгновенно начинает скачок во времени выполнения, и время от времени повторяется через 30 секунд.

Чтобы исправить, я эффективно обрезаю таблицу (на самом деле я sp_rename таблица)и мгновенно воссоздайте с тем же индексом).

Индексы не показывают большой фрагментации.

Как я могу диагностировать / что я делаю неправильно?Я знаю, что SQL Server может быть не лучшим для такого кольцевого буфера - на самом деле я тоже веду журнал в стек ELK, но это альтернативное хранилище, и я хотел бы сохранить его, если это возможно.

Примечание: я нахожусь на SQL Azure здесь