| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
warning)
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Rely on "__NR_prlimit64" availability and check GLIBC version only.
Take kernel version out of the picture.
This way it works on both CentOS 6 and 7.
Also, have test_contracts.py tests assume prlimit() is always available,
so that we will be notified (by failure).
Ref: #1758
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Preamble
=======
We have a [memory leak test suite](https://github.com/giampaolo/psutil/blob/e1ea2bccf8aea404dca0f79398f36f37217c45f6/psutil/tests/__init__.py#L897), which calls a function many times and fails if the process memory increased. We do this in order to detect missing `free()` or `Py_DECREF` calls in the C modules. When we do, then we have a memory leak.
The problem
==========
A problem we've been having for probably over 10 years, is the false positives. That's because the memory fluctuates. Sometimes it may increase (or even decrease!) due to how the OS handles memory, the Python's garbage collector, the fact that RSS is an approximation and who knows what else. So thus far we tried to compensate that by using the following logic:
- warmup (call fun 10 times)
- call the function many times (1000)
- if memory increased before/after calling function 1000 times, then keep calling it for another 3 secs
- if it still increased at all (> 0) then fail
This logic didn't really solve the problem, as we still had occasional false positives, especially lately on FreeBSD.
The solution
=========
This PR changes the internal algorithm so that in case of failure (mem > 0 after calling fun() N times) we retry the test for up to 5 times, increasing N (repetitions) each time, so we consider it a failure only if the memory **keeps increasing** between runs. So for instance, here's a legitimate failure:
```
psutil.tests.test_memory_leaks.TestModuleFunctionsLeaks.test_disk_partitions ...
Run #1: extra-mem=696.0K, per-call=3.5K, calls=200
Run #2: extra-mem=1.4M, per-call=3.5K, calls=400
Run #3: extra-mem=2.1M, per-call=3.5K, calls=600
Run #4: extra-mem=2.7M, per-call=3.5K, calls=800
Run #5: extra-mem=3.4M, per-call=3.5K, calls=1000
FAIL
```
If, on the other hand, the memory increased on one run (say 200 calls) but decreased on the next run (say 400 calls), then it clearly means it's a false positive, because memory consumption may be > 0 on second run, but if it's lower than the previous run with less repetitions, then it cannot possibly represent a leak (just a fluctuation):
```
psutil.tests.test_memory_leaks.TestModuleFunctionsLeaks.test_net_connections ...
Run #1: extra-mem=568.0K, per-call=2.8K, calls=200
Run #2: extra-mem=24.0K, per-call=61.4B, calls=400
OK
```
Note about mallinfo()
================
Aka #1275. `mallinfo()` on Linux is supposed to provide memory metrics about how many bytes gets allocated on the heap by `malloc()`, so it's supposed to be way more precise than RSS and also [USS](http://grodola.blogspot.com/2016/02/psutil-4-real-process-memory-and-environ.html). In another branch were I exposed it, I verified that fluctuations still occur even when using `mallinfo()` though, despite less often. So that means even `mallinfo()` would not grant 100% stability.
|
| |\ |
|
| | | |
|
| |\ \
| |/ |
|
| | | |
|
| | | |
|
| |\ \
| |/ |
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| |\ |
|
| | |
| |
| | |
Over the years I have accumulated different unit-tests which use dir() to get all process methods and test them in different circumstances. This produced a lot of code duplication. With this PR I introduce 2 new test classes (process_namespace and system_namespace) which declare all the method names and arguments in a single place, removing a lot cruft and code duplication.
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* `Process.wait()` on POSIX now returns an `enum` showing the negative which was used to terminate the process:
```python
>>> import psutil
>>> p = psutil.Process(9891)
>>> p.terminate()
>>> p.wait()
<Negsignal.SIGTERM: -15>
```
* the return value is cached so that the exit code can be retrieved on then next call, mimicking `subprocess.Popen.wait()`
* `Process` object provides more `status` and `exitcode` additional info on `str()` and `repr()`:
```
>>> proc
psutil.Process(pid=12739, name='python3', status='terminated', exitcode=<Negsigs.SIGTERM: -15>, started='15:08:20')
```
Extra:
* improved `wait()` doc
* reverted #1736: `psutil.Popen` uses original `subprocess.Popen.wait` method (safer)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Despite I recently implemented parallel tests on UNIX (#1709), TestFetchAllProcesses class is the slowest one to run because it gets all possible info for all processes in one go. In fact it's a singe unit-test, so it's not parallelized by the test runner. In here I used multiprocessing.Pool to do the trick.
On my main linux box (8 cores):
Before:
----------------------------------------------------------------------
Ran 1 test in 2.511s
After:
----------------------------------------------------------------------
Ran 1 test in 0.931s
On Windows (virtualized, 4 cores):
Before:
----------------------------------------------------------------------
Ran 1 test in 13.752s
After:
----------------------------------------------------------------------
Ran 1 test in 3.951s
|
| | |
|
| | |
|
| | |
|
| |
|
| |
...in order to accomodate Cygwin implementation.
|
| |
|
|
|
|
|
| |
Doing "make install" before any test is slow and not really necessary.
Instead do "make build", and remove the part import setuptools and test
psutil can be imported (do that in make install instead).
This way I went down from 0.8 secs (install phase before starting the test) to 0.3 secs!
|
| | |
|
| |
|
|
|
| |
Test files/dirs are now removed after each test. when invoked via self.get_testfn().
Until now test files were stored in a global variable and were removed at process exit, via atexit.register(), but this didn't work with parallel tests because the fork()ed workers use os._exit(0), preventing cleanup functions to run.
All test classes now inherit from PsutilTestCase class, which provides the most important methods requiring an automatic cleanup (get_test_subprocess() and others).
|
| |\ |
|
