Общее время процесса PROC SQL, понимание журнала

Question

Я хотел бы лучше понять журнал времени, чтобы улучшить производительность.

Мое реальное время обычно намного больше, чем время процессора. Это ожидается?

Разница связана с доступом к диску? Операции в памяти включены в процессорное время или в реальном времени?

Есть ли полезная информация об оптимизации производительности в других строках журнала?

Пример:

NOTE: PROCEDURE SQL used (Total process time):
      real time           9:06.00
      user cpu time       1:36.79
      system cpu time     19.11 seconds
      memory              7463.31k
      OS Memory           24628.00k
      Timestamp           06/07/2018 12:45:31 PM
      Page Faults                       7
      Page Reclaims                     1566
      Page Swaps                        0
      Voluntary Context Switches        370694
      Involuntary Context Switches      36835
      Block Input Operations            0
      Block Output Operations           0

Answer 1

Время ЦП - это объем обработки ЦП - сколько тактов ЦП было использовано. Это на ядро; он может быть больше реального времени, если используются несколько ядер (виртуальных или физических). Например, то, что требует интенсивной загрузки ЦП и работает с параллельной обработкой, использует 4 ядра на вашей машине в течение 2 минут, в режиме реального времени - 2 минуты, а время процессора - до 8 минут.

Реальное время - это буквально время между началом и окончанием работы. В случае proc sqlдо quit достигается - так что если вы уходите proc sql открыть без выхода, в реальном времени может быть, пока вы в следующий раз не запустите процесс.

В большинстве случаев разница между временем ЦП и реальным временем, как вы говорите, дисковым вводом-выводом - если вы читаете по сети или с вращающегося диска, вполне вероятно, что ваш дисковый ввод-вывод займет больше времени, чем ваш ЦП время.

Чтение "файла" из памяти не включается во время ЦП, за исключением случаев, когда оно включает ЦП.

Другие поля полезны для диагностики проблем производительности на разных уровнях. Объем используемой памяти может указывать на конкретные проблемы с вашим кодом (если он использует огромные объемы памяти, возможно, вы делаете что-то неэффективно).

Возможно, вы захотите прочитать некоторые статьи по эффективности и оптимизации SQL, например, Кирку Лафлеру, в частности, посмотрите обсуждение _METHOD и _TREE в конце. И, конечно же, в документации упоминаются различные способы получения дополнительной информации, такие как STIMER и FEEDBACK.