Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Java Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2]      все
 Re: Memory Leak?  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 7927
Если 88 это кол-во класслоадеров - то IMHO их как-то многовато. Оставание в памяти класслоадера == "классический баг с редиплоем"

IMHO & AFAIK

1) поскольку он классический, читать доки из-за чего такое происходит и как этого избежать (он вроде как-то связан с не очень хорошими практиками в пользовательском коде)
2) возможно менять версию сервера (ставить патчи) или даже сам сервер на другой (как минимум в томкатах с ним боролись из версии к версии)
3) забить нано-болт и вместо редиплоя перегружать сервер
26 сен 19, 15:57    [21980028]     Ответить | Цитировать Сообщить модератору
 Re: Memory Leak?  [new]
mayton
Member

Откуда: loopback
Сообщений: 42385
А 88 класслоадеров это много? Мне кажется зависит от.
26 сен 19, 15:58    [21980032]     Ответить | Цитировать Сообщить модератору
 Re: Memory Leak?  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 7927
mayton
А 88 класслоадеров это много? Мне кажется зависит от.

Мне не очень понятно, что это за цифра 88 (((

если это байт - то тогда мало
если кол-во в шутках - то тогда IMHO много
26 сен 19, 16:01    [21980041]     Ответить | Цитировать Сообщить модератору
 Re: Memory Leak?  [new]
ivanra
Member

Откуда:
Сообщений: 860
Leonid Kudryavtsev
mayton
А 88 класслоадеров это много? Мне кажется зависит от.

Мне не очень понятно, что это за цифра 88 (((

если это байт - то тогда мало
если кол-во в шутках - то тогда IMHO много

В данном случае 88 - это Shallow Heap - количество байт, которое объект занимает в памяти сам по себе.
Сколько там класслоадеров история умалчивает
26 сен 19, 16:04    [21980043]     Ответить | Цитировать Сообщить модератору
 Re: Memory Leak?  [new]
mayton
Member

Откуда: loopback
Сообщений: 42385
Я думаю что нужно позвать программиста который знает этот бизнес-домен.
И показать ему содержание зубчатого массива byte[461][] и спросить что єто
за данные? И ответ придет очень быстро. От данных пойдем к коду который их продуцирует.
26 сен 19, 16:07    [21980045]     Ответить | Цитировать Сообщить модератору
 Re: Memory Leak?  [new]
WGA
Member

Откуда:
Сообщений: 392
mayton
Я думаю что нужно позвать программиста который знает этот бизнес-домен.
И показать ему содержание зубчатого массива byte[461][] и спросить что єто
за данные? И ответ придет очень быстро. От данных пойдем к коду который их продуцирует.
Я знаю бизнес-домен и нашел, какой запрос выполняется, с каким параметром. Но не воспроизводится в "тепличных условиях", т.е. если просто дернуть REST-метод. Возможно, фактора редеплоя не хватает.

Меня смущает этот огромный ArrayList, в котором лежат массивы байтов. Учитывая, что в нем лежат не java-объекты, а некое сериализованное представление доменных объектов, начинаю подозревать postgresql драйвер. Только не воспроизводится, зараза ((

А можно ли как-нибудь из анализа heap dump определить, в какой точке стектрейса определена локальная переменная?
26 сен 19, 22:09    [21980330]     Ответить | Цитировать Сообщить модератору
 Re: Memory Leak?  [new]
WGA
Member

Откуда:
Сообщений: 392
WGA
А можно ли как-нибудь из анализа heap dump определить, в какой точке стектрейса определена локальная переменная?
В смысле, в каком методе определена.
26 сен 19, 22:26    [21980347]     Ответить | Цитировать Сообщить модератору
 Re: Memory Leak?  [new]
vas0
Member

Откуда: Таможенный союз (Россия, Казахстан)
Сообщений: 1279
WGA
WGA
А можно ли как-нибудь из анализа heap dump определить, в какой точке стектрейса определена локальная переменная?
В смысле, в каком методе определена.
Локальные переменные же создаются в стековой памяти, а не в куче. Они GC напрягать вроде как не могут.

У тебя поля каких объектов, ссылки на которые так и остаются и могут быть собраны GC.
26 сен 19, 22:34    [21980354]     Ответить | Цитировать Сообщить модератору
 Re: Memory Leak?  [new]
WGA
Member

Откуда:
Сообщений: 392
Я нашел, где сжирается такое огромное количество памяти, посмотрев на исходники JDBC драйвера Postgresql.
  protected void processResults(ResultHandler handler, int flags) throws IOException {
    boolean noResults = (flags & QueryExecutor.QUERY_NO_RESULTS) != 0;
    boolean bothRowsAndStatus = (flags & QueryExecutor.QUERY_BOTH_ROWS_AND_STATUS) != 0;

    List<byte[][]> tuples = null;

    int c;
    boolean endQuery = false;

    // At the end of a command execution we have the CommandComplete
    // message to tell us we're done, but with a describeOnly command
    // we have no real flag to let us know we're done. We've got to
    // look for the next RowDescription or NoData message and return
    // from there.
    boolean doneAfterRowDescNoData = false;

    while (!endQuery) {
      c = pgStream.receiveChar();
      switch (c) {
............................
        case 'D': // Data Transfer (ongoing Execute response)
          byte[][] tuple = null;
          try {
            tuple = pgStream.receiveTupleV3();
          } catch (OutOfMemoryError oome) {
            if (!noResults) {
              handler.handleError(
                  new PSQLException(GT.tr("Ran out of memory retrieving query results."),
                      PSQLState.OUT_OF_MEMORY, oome));
            }
          }
Вот только для этой компании нет столько данных. И вообще данных немного.
27 сен 19, 09:16    [21980502]     Ответить | Цитировать Сообщить модератору
 Re: Memory Leak?  [new]
WGA
Member

Откуда:
Сообщений: 392
WGA
WGA
А можно ли как-нибудь из анализа heap dump определить, в какой точке стектрейса определена локальная переменная?
В смысле, в каком методе определена.
Насколько я знаю, переменная непримитивного типа - это ссылка. Сама переменная живет в стеке, а вот данные - в куче. С трудом представляю себе 1 гигабайт в стеке...

В общем, источник OOM локализован, вопрос закрыт. Осталось понять, на каких данных все это происходит.
Всем спасибо.
27 сен 19, 09:42    [21980516]     Ответить | Цитировать Сообщить модератору
 Re: Memory Leak?  [new]
ivanra
Member

Откуда:
Сообщений: 860
WGA,
в этом цикле в исходниках драйвера
    while (!endQuery) {
посмотри где endQuery присваивается true и почему этого не происходит.
И кроме того, можно посмотреть, что за запрос выполнялся. На потоке вызвать контекстное меню java basics - Thread overview and stacks - и там для каждой строки стека будут доступны локальные переменные. Найди в этом стеке SQL и проверь
27 сен 19, 10:20    [21980574]     Ответить | Цитировать Сообщить модератору
 Re: Memory Leak?  [new]
WGA
Member

Откуда:
Сообщений: 392
ivanra
WGA,
в этом цикле в исходниках драйвера
    while (!endQuery) {
посмотри где endQuery присваивается true и почему этого не происходит.
И кроме того, можно посмотреть, что за запрос выполнялся. На потоке вызвать контекстное меню java basics - Thread overview and stacks - и там для каждой строки стека будут доступны локальные переменные. Найди в этом стеке SQL и проверь
Про endQuery верно подмечено, спасибо. Это локальная переменная, переключается в true на определенные коды-команд транспортного протокола. В это switch'е это
// эта ветка неинтересна
        case 'S': // Parameter Status
          try {
            receiveParameterStatus();
          } catch (SQLException e) {
            handler.handleError(e);
            endQuery = true;
          }
          break;
...............
// а вот здесь возможно зацикливание, при изменении статуса транзакции
        case 'Z': // Ready For Query (eventual response to Sync)
          receiveRFQ();
          if (!pendingExecuteQueue.isEmpty() && pendingExecuteQueue.peekFirst().asSimple) {
            tuples = null;

            ExecuteRequest executeRequest = pendingExecuteQueue.removeFirst();
            // Simple queries might return several resultsets, thus we clear
            // fields, so queries like "select 1;update; select2" will properly
            // identify that "update" did not return any results
            executeRequest.query.setFields(null);

            pendingDescribePortalQueue.removeFirst();
            if (!pendingExecuteQueue.isEmpty()) {
              if (getTransactionState() == TransactionState.IDLE) {
                handler.secureProgress();
              }
// вот здесь!!!
              // process subsequent results (e.g. for cases like batched execution of simple 'Q' queries)
              break;
            }
          }
          endQuery = true;
27 сен 19, 11:35    [21980682]     Ответить | Цитировать Сообщить модератору
 Re: Memory Leak?  [new]
Leonid Kudryavtsev
Member

Откуда:
Сообщений: 7927
Если "....И похоже, что они остаются в памяти только при редеплое, иначе бы прод бы падал с завидной регулярностью, чего нет в действительности... " и "...при редеплое ссылки остаются и держат как heap, так и metaspace,..." правда, то смысла копаться в коде нет.

Ну не работает редиплой и не работает. Честно говоря, мне проблема вообще не понятна, вместо редиплоя перегрузить сервер и не парится. Или читать доки по Вашему апп-серверу и патчить или брать нормальный app сервер.

сколько программистов нужно. что бы починить редиплой - ни одного, it is a problem of system administrator

IMHO & AFAIK

p.s.
в 10-ой версии точно баги были, гугля тут же нашел WFLY-7037 от 17 года.
и в 8-ой версии были WFLY-6173
p.p.s.
опен соурс, он и есть опен соурс ))) работа программистов видна: одни программисты баги чинят, другие программисты их обратно вносят )))
27 сен 19, 15:04    [21980971]     Ответить | Цитировать Сообщить модератору
 Re: Memory Leak?  [new]
andreykaT
Member

Откуда:
Сообщений: 2421
Leonid Kudryavtsev
Если 88 это кол-во класслоадеров - то IMHO их как-то многовато. Оставание в памяти класслоадера == "классический баг с редиплоем"

IMHO & AFAIK

1) поскольку он классический, читать доки из-за чего такое происходит и как этого избежать (он вроде как-то связан с не очень хорошими практиками в пользовательском коде)
2) возможно менять версию сервера (ставить патчи) или даже сам сервер на другой (как минимум в томкатах с ним боролись из версии к версии)
3) забить нано-болт и вместо редиплоя перегружать сервер

где то читал что если делать постоянно редеплой, то сервер начинает дозабивать пермген до тех пор пока он не кончится. а потом да он кончается и всё. но вроде пермген убрали в 8+? не?
3 окт 19, 17:35    [21986104]     Ответить | Цитировать Сообщить модератору
 Re: Memory Leak?  [new]
забыл ник
Member

Откуда:
Сообщений: 3024
andreykaT
Leonid Kudryavtsev
Если 88 это кол-во класслоадеров - то IMHO их как-то многовато. Оставание в памяти класслоадера == "классический баг с редиплоем"

IMHO & AFAIK

1) поскольку он классический, читать доки из-за чего такое происходит и как этого избежать (он вроде как-то связан с не очень хорошими практиками в пользовательском коде)
2) возможно менять версию сервера (ставить патчи) или даже сам сервер на другой (как минимум в томкатах с ним боролись из версии к версии)
3) забить нано-болт и вместо редиплоя перегружать сервер

где то читал что если делать постоянно редеплой, то сервер начинает дозабивать пермген до тех пор пока он не кончится. а потом да он кончается и всё. но вроде пермген убрали в 8+? не?


Дело не в пермгене , если все правильно сделать то не будет никаких ликов
3 окт 19, 18:20    [21986152]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2]      все
Все форумы / Java Ответить