Conversation

Notices

1. musicman (musicman@nu.federati.net)'s status on Thursday, 29-Apr-2021 17:30:00 EDT musicman
   How many times would you expect a full gc in a 7 hour window? #java
   1. lnxw48a1 (lnxw48a1@nu.federati.net)'s status on Thursday, 29-Apr-2021 17:40:57 EDT lnxw48a1

      in reply to
      @musicman I would expect that to vary, based on how many objects it creates / allocates.
      1. lnxw48a1 (lnxw48a1@nu.federati.net)'s status on Thursday, 29-Apr-2021 20:40:16 EDT lnxw48a1

         in reply to
         @musicman By that, I mean I don't think there is a set number. It will depend on the program and how actively it is used.
         1. musicman (musicman@nu.federati.net)'s status on Friday, 30-Apr-2021 09:10:41 EDT musicman

            in reply to
            I should have specified, a well-functioning java app. At some level, too many full gcs is going to be bad. I was trying to figure out that number. Suffice it to say, my research suggests that my customer is WAY over the limit.
            1. lnxw48a1 (lnxw48a1@nu.federati.net)'s status on Friday, 30-Apr-2021 19:20:51 EDT lnxw48a1

               in reply to
               @musicman I understand what you're getting at. I don't think there is a hard and fast rule. But if gc pauses are noticeably affecting the program, there's likely something wrong.
               
               Now the question is, is the issue appearing in software you support, or in some custom code that $CUSTOMER wrote? (And also, is it because of a poorly done program or because $PROGRAM is being used in ways it isn't designed to handle?)
               1. lnxw48a1 (lnxw48a1@nu.federati.net)'s status on Friday, 30-Apr-2021 19:23:06 EDT lnxw48a1

                  in reply to
                  Sorry I can't be more specific, but I haven't used #Java in my work in over a decade.
                  1. musicman (musicman@nu.federati.net)'s status on Monday, 03-May-2021 12:28:20 EDT musicman

                     in reply to
                     customer is running a 72-hour test. I'm not sure if they are trying to test a DDoS or what, but the test seems to reliably fail around the 30 hour mark. Now, I haven't seen anything from the actual test. I think there is probably a security or application team involved and I am working with the systems team.
                     
                     In any case, Infinispan is known to not survive gc because as a cache, it has a lot timeout. My thought was maybe they were having full gcs every 30 hours or so, but turns out they had 1689 full gcs in 7 hours. I told them that if they were trying to test full gcs, they needed to not test that often because it's not a realistic test. As far as the log was concerned, they were not actually able to evacuate properly, so that's one reason the gcs kept happening. They old gave the JVM 8GB RAM though. None of this makes any sense!
                     
                     idk what they ended up changing, but they are running a new 72-hour test now, so something I said must have made sense to them.