Windows bench_command memory tracking fails
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 20/100
- Tipo di issue
- Bug
- Chiarezza
- Da chiarire
- Stato di attività
- Ferma
- Stack tecnologico
- python
- Ambito
- performance
Direzione di ricerca
Inizia riproducendo il benchmarking dei comandi Windows e leggi le sezioni referenziate di pyperf/_process_time.py, _win_memory.py, _runner.py e _worker.py. Confronta il modo in cui ogni piattaforma seleziona il monitoraggio della memoria e quali misurazioni si aspetta il codice esistente. Il lavoro è completato quando è stata selezionata una metrica di memoria concordata, i benchmark dei comandi vengono eseguiti correttamente su Windows e il comportamento rilevante è coperto dai test.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Creating a new issue to track a PR I'm working on to fix the issue in the title. Related issue from May 2021: #97
I was attempting to track the memory usage of command benchmarks on Windows, but got the following errors when doing so:
Traceback (most recent call last):
File "<frozen runpy>", line 198, in _run_module_as_main
File "<frozen runpy>", line 88, in _run_code
File "D:\my_project\.venv\Lib\site-packages\pyperf\__main__.py", line 769, in <module>
main()
File "D:\my_project\.venv\Lib\site-packages\pyperf\__main__.py", line 765, in main
func()
File "D:\my_project\.venv\Lib\site-packages\pyperf\__main__.py", line 734, in cmd_bench_command
runner.bench_command(name, command)
File "D:\my_project\.venv\Lib\site-packages\pyperf\_runner.py", line 747, in bench_command
return self._main(task)
^^^^^^^^^^^^^^^^
File "D:\my_project\.venv\Lib\site-packages\pyperf\_runner.py", line 460, in _main
bench = self._worker(task)
^^^^^^^^^^^^^^^^^^
File "D:\my_project\.venv\Lib\site-packages\pyperf\_runner.py", line 434, in _worker
run = task.create_run()
^^^^^^^^^^^^^^^^^
File "D:\my_project\.venv\Lib\site-packages\pyperf\_worker.py", line 299, in create_run
self.compute()
File "D:\my_project\.venv\Lib\site-packages\pyperf\_command.py", line 70, in compute
raise RuntimeError("failed to get the process RSS")
RuntimeError: failed to get the process RSS
Traceback (most recent call last):
File "<frozen runpy>", line 198, in _run_module_as_main
File "<frozen runpy>", line 88, in _run_code
File "\.venv\Scripts\pyperf.exe\__main__.py", line 10, in <module>
File "D:\my_project\.venv\Lib\site-packages\pyperf\__main__.py", line 765, in main
func()
File "D:\my_project\.venv\Lib\site-packages\pyperf\__main__.py", line 734, in cmd_bench_command
runner.bench_command(name, command)
File "D:\my_project\.venv\Lib\site-packages\pyperf\_runner.py", line 747, in bench_command
return self._main(task)
^^^^^^^^^^^^^^^^
File "D:\my_project\.venv\Lib\site-packages\pyperf\_runner.py", line 465, in _main
bench = self._manager()
^^^^^^^^^^^^^^^
File "D:\my_project\.venv\Lib\site-packages\pyperf\_runner.py", line 678, in _manager
bench = Manager(self).create_bench()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "D:\my_project\.venv\Lib\site-packages\pyperf\_manager.py", line 243, in create_bench
worker_bench, run = self.create_worker_bench()
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "D:\my_project\.venv\Lib\site-packages\pyperf\_manager.py", line 142, in create_worker_bench
suite = self.create_suite()
^^^^^^^^^^^^^^^^^^^
File "D:\my_project\.venv\Lib\site-packages\pyperf\_manager.py", line 132, in create_suite
suite = self.spawn_worker(self.calibrate_loops, 0)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "D:\my_project\.venv\Lib\site-packages\pyperf\_manager.py", line 118, in spawn_worker
raise RuntimeError("%s failed with exit code %s"
RuntimeError: D:\my_project\.venv\Scripts\python.exe failed with exit code 1
I debugged my way through the code and ended up getting the root cause, which is located here: https://github.com/psf/pyperf/blob/e0610c2f263c300de870e7bc8e494d46e0fd71be/pyperf/_process_time.py#L25-L42
In short, this function gets the current process resident set size by using the resource library, but this library is only available on Linux. When run on Windows, this function simply returns 0, which causes the downstream callers to see this as an error and fail running the benchmark entirely.
I began working on a fork where I instead use psutil to get the current process' RSS, but I noticed that psutil.Process().memory_info().rss returns higher values than the measurements from the resource library. I'm seeing roughly 25% - 35% higher RSS size with psutil`, so that leads to a dilemma in terms of accuracy across operating systems. We have a few options:
psutilworks cross-platform, but therssvalues are not accurate with what theresourcemodule gets. We can opt to only usepsutilmoving forward, but that would invalidate all existing command benchmark results until they are re-run.- We can use
psutilonly for Windows systems, but this leads to a memory usage discrepancy between operating systems. On my Mac Mini, theresourceandpsutilRSS sizes did not match by a wide margin, so for Windows systems it would falsely appear to have higher memory usage than Mac systems (and presumably Linux ones as well). - We can use some other data point, such as the Unique Set Size from
psutilthroughpsutil.Process().memory_full_info().uss. USS is closer to what theresourcemodule gets for RSS, but now USS is about 15% smaller than RSS from theresourcemodule. USS is supposed to be the closest representation of the process memory usage, which should be more ideal than RSS or peak RSS
I'm not aware of any other ways to get the memory usage of a process without writing some C bindings to do so. What's more confusing is that there is also the _win_memory.py file that uses Windows-native functionality to track memory usage, but from my testing that's not used correctly - if it was then I wouldn't be getting the above error.
I see in both _runner.py and _worker.py that we break down what method to use based on what OS is running. If we go with using psutil for the unifying the memory tracking of command benchmarks, should we do the same for regular benchmarks?
- Lingua principale
- Python
- Stelle
- 967
- Fork
- 112
- Merge medio
- 5g 8h
- PR unite (30g)
- 9
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di psf/pyperf
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
I maintainer di solito rispondono entro 1 giorno
-
Improve Type System for `pyperf`Forse già presa @DebanKsahu l’ha presa 69 giorni fa. Aperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 32/100
I maintainer di solito rispondono entro 1 giorno
-
Extend hook's teardown metadata with warmup/calibration flagsForse già presa @maurycy l’ha presa 170 giorni fa. Aperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
psf/pyperf#239 · 12 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
2.6.2: sphinx warnings `reference target not found`Forse già presa @amritamishra01 l’ha presa 356 giorni fa. Aperta
Difficoltà 3/5 1-2 giorni Idoneità per principianti 42/100
I maintainer di solito rispondono entro 1 giorno
Issue simili
-
add entry to blockAperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 65/100
StevenBlack/hosts#3299 ·
-
`garak --report` overwrites the input report when its name has no ".report"Forse già presa @0z5a l’ha presa oggi. Apertaneeds-triage
Difficoltà 2/5 Mezza giornata Idoneità per principianti 72/100
I maintainer di solito rispondono entro 2 giorni
-
plot_graph crashes when a mesh node has no m2m edgeForse già presa @tygvi l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
mllam/neural-lam#883 · 1 commento ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
future-agi/future-agi#4092 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
transcript analytics: a text whose only protected spans the prose pass redacts is withheld wholeAperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 82/100
WingedGuardian/GENesis-AGI#4641 ·
I maintainer di solito rispondono entro 1 giorno