On Mon, 27 Jun 2016 00:21:01 -0700 (PDT) feng19910...@gmail.com wrote: [...] > After running several times the system file cache becomes very large > > CONTAINER CPU % MEM USAGE / LIMIT MEM % NET > I/O BLOCK I/O zyapi_8011 38.47% 6.442 GB / 6.442 GB > 100.00% 0 B / 0 B 0 B / 115.4 MB zyapi_8012 36.90% > 6.442 GB / 6.442 GB 99.99% 0 B / 0 B 0 B / 115.6 MB > It's hard to tell what that "MEM USAGE" gauge really measures. Go runtime is known to its somewhat peculiar approach to memory management which can be vaguely summarized like this:
* It uses a so-called "arena allocator" which basically tells the OS to give it a big contiguous chunk of memory, from which the runtime then cuts pieces for the data it manages. * The memory freed by the GC is not really "returned" to the OS but rather is marked as being free to be reused by the OS any time it sees the need to do that. These things combined mean that: 1) Measuring "virtual set size" (VSZ) of a Go process has no sense. 2) Measuring "resident set size" (RSS) has a bit more sense but still not much. To get real statistics on memory usage of the runtime of a Go program, you need to profile it. Look at this recent thread [1] for instance. 1. https://groups.google.com/d/topic/golang-nuts/IfILC-wllaI/discussion -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
