On Thu, Aug 1, 2013 at 6:11 PM, Shawn Heisey <s...@elyograg.org> wrote:
> On 8/1/2013 2:08 PM, Roman Chyla wrote: > >> Hi, here is a short post describing the results of the yesterday run with >> added parameters as per Shawn's recommendation, have fun getting confused >> ;) >> >> http://29min.wordpress.com/**2013/08/01/measuring-solr-**performance-ii/<http://29min.wordpress.com/2013/08/01/measuring-solr-performance-ii/> >> > > I am having a very difficult time with the graphs. I have no idea what > I'm looking at. The graphs are probably self-explanatory to you, because > you created them and you've been staring at them for hours. There are both > lines and shaded areas, and I can't tell what they mean. > I know :) but I am rather investing time in preparing a better test, because as you said, worst case is the aim - and I would like to trigger the worst case (btw, all these remaining GC configs have comparable max execution time of less than 1.5s - that is the worst case in their case so far and with so a few measurements, there is no meaningful analysis of significance between them). But when I look at the heights of the areas, in the charts, the higher means worse - so the yellow seems to be the worst (g1-custom), your preferred configuration (i think it was cms-x1, green) seems better than g1-custom. But 'SEEMS' is an important qualifier here > > Tables with numbers, if they have a good legend, would be awesome. > tables are there, just hidden, you would have to run it - the code is there as well... > > One thing I'd like to see, and when I have some time of my own I will do > some comprehensive long-term comparisons on production systems, is to see > what adding or changing *one* GC tuning parameter at a time does, so I can > find the ideal settings and have some idea of which settings make the most > difference. > > My concern with garbage collection tuning has been mostly worst-case > scenario pauses. I certainly do want averages to come down, but it's > really the worst-case that concerns me. > > Let's say that one of my typical queries takes 100 milliseconds on average > with my GC config. Somebody comes up with another GC config that makes the > same query take 25 milliseconds or less on average. If that config also > results in rare stop-the-world garbage collections that take 5 full > seconds, I won't be using it. I'd rather deal with the slower average > queries than the GC pause problems. > exactly > > I had to let my production systems run for days with jHiccup before I > really noticed that I had a GC pause problem. I've since learned that if I > look at GC logs with GCLogViewer, I can get much the same information. > well, and instead of days, I think it is possible to trigger the worst case scenario in a matter of hours (but that is my conjecture, to be proven wrong... ;)) roman > > Thanks, > Shawn > >
