Try perf record a little while after restart (give it enough warmup room after restart), and then again once sys% starts to match usr%. Offender should show up if your put them side by side.
On Mar 29, 2017 6:23 PM, "'Matt Fleming' via mechanical-sympathy" < [email protected]> wrote: > Hi, > > Have you tried using the usual kernel performance profling tools to see > where the system is spending its time? > > Matt > > On 28 March 2017 at 13:45, Erik Svensson <[email protected]> wrote: > >> Howdy guys! >> >> My journey into mystification with virtual environments continues. >> >> We have a number of market data feeds from a number of markets. Each >> market feed is running on its own virtual host. >> I’m keeping an eye of gc logs and such. >> One thing I noticed after a while is that kernel time seems to grow over >> time, eventually exceeding user time. If you reboot the machine it goes >> back to ‘normal’ and then starts over again. >> I have never seen this behaviour with physical hw. >> >> Does this ring a bell with anyone? Right now I’m thinking about rebooting >> the virtual hosts every weekend but that is an unsatisfactory solution. >> >> cheers >> Erik >> >> -- >> You received this message because you are subscribed to the Google Groups >> "mechanical-sympathy" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google Groups > "mechanical-sympathy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
