It would be useful to get a 'jmap -histo:live' report as well, which will only have items that remain after a full GC.
However, a high churn of short lived Jackson objects is not expected here unless the user is reading Json serialized files and not Avro binary. Avro Data Files only contain binary encoded Avro content. It would be surprising to see many Jackson objects here if reading Avro Data Files, because we expect to use Jackson to parse an Avro schema from json only once or twice per file. After the schema is parsed, Jackson shouldn't be used. A hundred thousand DeserializationConfig instances means that isn't the case. On 6/1/11 5:13 PM, "Tatu Saloranta" <[email protected]> wrote: >On Wed, Jun 1, 2011 at 1:45 PM, Scott Carey <[email protected]> >wrote: >> Lower down this list of object counts, what are the top >>org.apache.avro.** >> object counts? >> How many AvroSerialization objects? How many AvroMapper, AvroWrapper, >>etc? >> What about org.apache.hadoop.** objects? > >Also: is this jmap view of live objects, or just dump of ALL objects, >live and dead? >It seems like dump of latter, as most Jackson objects are short-term >things created for per-invocation purposes, and discarded after >process is complete. High count is not necessarily surprising for >high-throughput systems; it is only odd if these are actual live >objects. > >-+ Tatu +-
