Uri Guttman wrote: > if you run out of vram and you didn't expect it, wouldn't that signify a > possible leak?
No, not necessarily. This is code that processes large flat files, supplementing them with information pulled from a few large lookup tables which are loaded into memory, as well as information retrieved from web services. (Pretty horrible architecture...) While the main file being processed is never entirely memory resident, some data from each record is aggregated. That and the lookup tables are expected to remain resident for the life of the process. So the OOM could be a result of an inefficiency in how the resident data is stored (due to some recently introduced change), or an increase in the quantity of data. (It's believed the data quantity hasn't changed significantly.) Or, it could be a leak, as you suggest, due to ancillary data from the records of the main file not getting cleaned up after the record is written. I expect the code is littered with leaks and storage inefficiencies, but at the moment I'm trying to track down what recent change might have pushed it over the edge. > maybe Devel::Leak will help. Maybe. More on that in the next message. -Tom -- Tom Metro Venture Logic, Newton, MA, USA "Enterprise solutions through open source." Professional Profile: http://tmetro.venturelogic.com/ _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
