Closed EricR86 closed 8 years ago
Original comment by Eric Roberts (Bitbucket: ericr86, GitHub: ericr86).
--num-instances
seems to be tied to this issue.
Very little memory is "leaked" if at all for --num-instances 2
(still multithreaded).
However when --num-instances
when set to 10, significant memory seems to "leak" by the megabyte within a minute.
This results were consistent with Segway currently (tip) and the Segway 1.2.0 release.
I cannot run an earlier release of Segway since the cluster system is not recognized.
Original comment by Eric Roberts (Bitbucket: ericr86, GitHub: ericr86).
It is worth noting all python string objects assigned to DRMAA job template attributes are automatically "cast" to unicode objects. This is done by the Python DRMAA API by overriding the __set__
operator and calling the C library reference implementation. It is the C library implementation call that returns a unicode object.
Original comment by Rachel Chan (Bitbucket: rcwchan).
Fixed in pull request #54 ( @ericr86 I am unable to mark this as resolved)
Original comment by Eric Roberts (Bitbucket: ericr86, GitHub: ericr86).
Fixed in pull request #54
Original report (BitBucket issue) by Eric Roberts (Bitbucket: ericr86, GitHub: ericr86).
The segway process (and not the jobs it spawns) is taking up a significant amount of memory for longer running jobs. The memory usage increases the longer segway is running and submitting jobs.
Here is an example of memory usage from top on an SGE Cluster:
Where 47.3 gigs is the virtual memory given to the process and 45g is the resident set size of the process.
Memory (python) profiling information was injected into the process to find out the following using guppy and pyringe:
Guppy documentation is incredibly difficult to come by especially with the syntax used. It is essentially a declarative domain specific language to select information about the python memory of a given program. Notably
.heap()
returns a selection of the entire Python heap reachable by python objects and.heapu()
return the heap of unreachable python objects (that should be garbage collected). It is the heap itself that shows there is an unreasonable amount of unicode objects taking up a significant amount of memory.byrcs
selects on the heap or part of the heap and organizes by "referrers by kind (class)".byvia
does the something similar except it shows where the objects are being referred via.From the preliminary data it looks like there is a massive list (of a list?) of unicode objects. Presumably this list grows the longer segway runs.