Блог

Я хочу получить все отправленные списки изменений за определенный день, и команда, которую я использовал, приведена ниже:

 $ p4 changes -s submitted //...@2020/11/03,2020/11/04
  

Итак, я считаю, что приведенная выше команда должна предоставить мне список всех отправленных списков изменений с 3 ноября 2020 года по 4 ноября 2020 года.

Вместо этого я вижу это:

 Too many rows scanned (over 55000000); see 'p4 help maxscanrows'.
  

Что я должен сделать, чтобы избавиться от этого?

Параметр «maxscanrows» (который настраивается администратором для каждой группы пользователей) ограничивает количество строк базы данных, которые сканируются любым заданным запросом. В случае p4 changes , есть два разных способа выполнения запроса, в зависимости от переданных вами аргументов:

1. Если указан путь, db.rev проверяются записи, соответствующие пути, и из этого набора выбираются списки изменений, соответствующие диапазону изменений. db.rev индексируется по пути.
2. Если путь не указан, и если диапазон изменений не зависит от данных ревизии (например, дат, которые содержатся в самих списках изменений), db.change записи сканируются, чтобы найти те, которые соответствуют диапазону.

Исключением из (1) является то, что если запрашивается максимальное количество списков изменений, db.revcx может использоваться, если путь очень широкий. Эта логика может быть настроена и описана в p4 help undoc :

     dm.changes.thresh1     50K 'changes -mx path' uses db.revcx if...
    dm.changes.thresh2     10K ...if < thresh2 of thresh1 db.rev match
  

Для вашего конкретного случая, я думаю, вы обнаружите, что:

 p4 changes -s submitted @2020/11/03,2020/11/04
  

выполняется намного быстрее (и без превышения предела maxscanrows), потому что он будет искать на основе db.change .

Как вы отметили в своем собственном ответе, сужение пути к хранилищу является еще одним возможным решением, поскольку это уменьшит количество db.rev сканируемых строк — однако это даст вам разные результаты (и в зависимости от того, насколько вы сузите путь к хранилищу, это все равно может быть не так быстро, как простое сканирование таблицы изменений).

Чтобы увидеть, к каким конкретным таблицам обращается данный запрос, и сколько строк каждого из них доступно, вы можете использовать -Zdbstat глобальный флаг:

 C:Perforcetest>p4 -Zdbstat changes -s submitted @2019/11/03,2020/11/04
...
--- db.revcx
---   pages in out cached 1 0 1
---   locks read/write 0/0 rows get pos scan put del 0 0 0 0 0
---   peek count 1 wait held total/max 0ms 0ms/0ms 0ms
...
--- db.change
---   pages in out cached 5 0 4
---   locks read/write 0/0 rows get pos scan put del 0 1 127 0 0
---   peek count 1 wait held total/max 0ms 0ms/0ms 0ms
...
  

против:

 C:Perforcetest>p4 -Zdbstat changes -s submitted //...@2019/11/03,2020/11/04
...
--- db.rev
---   pages in out cached 27 0 26
---   locks read/write 0/0 rows get pos scan put del 0 1 868 0 0
---   peek count 1 wait held total/max 0ms 16ms/0ms 16ms
...
--- db.change
---   pages in out cached 4 0 3
---   locks read/write 0/0 rows get pos scan put del 0 64 128 0 0
---   peek count 1 wait held total/max 0ms 0ms/0ms 0ms
...
  

Это может быть очень полезным инструментом для настройки запросов на эффективность в подобных случаях, когда у вас есть несколько способов получить доступ к определенной части данных, и особенно для понимания того, почему вы сталкиваетесь с определенными ограничениями производительности.

Вероятно, нам следует использовать это:

изменения в p4 //path/to/depot/…@2020/11/03 ,2020/11/05