Эта статья взята из архитектуры облачной эры, автор: Ли Яньпэн.
предисловие
Несмотря на то, что прошло полгода, процесс расследования онлайн-инцидентов OOM все еще свеж в моей памяти, и каждый шаг жив в моей памяти Благодаря мощной поддержке бизнес-группы, системного отдела, группы измерения стресса и отдел мониторинга и экстренной помощи для группы архитектуры, это стало возможным.Выявилась проблема с памятью Java.После более чем полугодовой комплексной трансформации метода резки журнала приложения, в основном нет проблемы OOM.Онлайн-сервис работает очень хорошо, что сыграло большую роль в обеспечении доступности.Если вы испытываете OOM, чтение этой статьи будет очень поучительным.
Become OOM Killer
Все мы знаем, что управление памятью JVM автоматизировано, и программный указатель языка Java не нужно освобождать вручную разработчиком. GC JVM автоматически утилизирует его. Однако, если программирование неправильное, JVM по-прежнему будет вызывать утечку памяти, что приведет к созданию программ Java.Ошибка OutOfMemoryError (OOM).
Причины ошибки OutOfMemoryError включают в себя:
java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: пространство PermGen и его решение
java.lang.OutOfMemoryError: unable to create new native thread
java.lang.OutOfMemoryError: превышен лимит накладных расходов GC
Для первого исключения это означает, что места в куче Java недостаточно.Когда приложение запрашивает дополнительную память, а память кучи Java больше не может удовлетворить потребности приложения в памяти, это исключение будет выдано.
Для второго типа исключения это означает, что в постоянном бэнде Java (области методов) недостаточно места. Постоянный бэнд используется для хранения байт-кода и длинного константного пула класса. После загрузки байт-кода класса он Хранится в этой области Область кучи отличается, большинство реализаций JVM не собирают мусор в постоянной полосе, поэтому эта проблема возникает всякий раз, когда загружается слишком много классов. Обычные приложения не генерируют эту ошибку. Однако для веб-серверов будет большое количество JSP. JSP динамически компилируются в классы сервлетов Java во время выполнения, а затем загружаются в область методов. Поэтому генерируется слишком много JSP. Это исключение может генерироваться веб-проектами JSP.
Для третьего исключения существенной причиной является то, что создается слишком много потоков, а количество потоков, которые могут быть созданы, ограничено, что приводит к возникновению этого исключения.
Что касается четвертого исключения, параллельный или параллельный сборщик слишком долго собирает сборщик мусора, более 98 % времени используется для GC и восстанавливается менее 2 % памяти кучи, а затем это исключение выдается для раннего предупреждения. Он используется для предотвращения правильной работы приложения из-за слишком малого объема памяти.
Следующие два исключения связаны с OOM, но они не связаны абсолютно.
java.lang.StackOverflowError…
java.net.SocketException: Too many open files
Для первого исключения поток JVM занимает стек потоков из-за слишком большого количества уровней рекурсии или вызова методов.Размер стека потоков по умолчанию составляет 1M.
Второе исключение связано с тем, что в системе есть ограничение на использование дескрипторов файлов, а дескриптор файла, используемый приложением, превышает это ограничение, что и вызовет эту проблему.
Основные знания, связанные с OOM, были представлены выше.Далее мы начнем описывать процесс обнаружения и решения проблемы OOM, с которой столкнулся автор.
1. Явление, вызывающее проблему
В течение определенного периода времени мы обнаружили, что различные бизнес-службы стали время от времени сообщать об исключениях OOM, иногда днем, иногда ночью, иногда с базовой службой A, а иногда с службой верхнего уровня B. возникает служба C, а иногда возникает служба D более низкого уровня, и шаблона вообще нет.
Исключением, вызывающим проблему, является следующее:
Caused by: java.lang.OutOfMemoryError: unable to create new native thread at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:597)
at java.util.Timer.<init>(Timer.java:154)скопировать код2. Идеи и процессы решения проблем
После тщательного наблюдения выясняется, что хотя проблема возникает в разных сервисных пулах в разное время, вероятность возникновения высока в 0:00 вечера, есть и другие случаи, но все они в час.
Это правило очень важно.Хотя это не время, в основном это происходит в течение всего часа, и большинство из них приходится на 0 часов вечера. Думая с этой точки зрения, имеет ли система время на час или 0:00, уточните у технического специалиста, отвечающего за каждую бизнес-систему, в которой есть проблема, нет запланированной задачи на 0:00, и есть запланированные задачи на другое время на час, но отличается от времени, когда возникает проблема.Согласен, эта идея не работает.
Пока нам не удалось продолжить анализ закона явлений, поэтому давайте рассмотрим саму ошибку:
java.lang.OutOfMemoryError: unable to create new native thread
Как следует из названия, причина ошибки в том, что приложение не может создать поток, но приложению все равно необходимо создать поток. Почему программы не могут создавать потоки?
Есть две конкретные причины для этого исключения:
Поскольку поток использует слишком много ресурсов, операционная система больше не может предоставлять ресурсы приложению.
Операционная система устанавливает максимальное количество потоков, которое может создать приложение, и максимально допустимое количество было достигнуто.
Первый ресурс выше относится к памяти, а во втором пункте потоки реализуются с помощью облегченных процессов под Linux, поэтому максимальное количество потоков также является максимальным количеством процессов, разрешенных операционной системой.
Вычисления в памяти
Максимально доступная память в операционной системе убирает часть, используемую самой операционной системой, а остальное может обслуживать определенный процесс.В процессе JVM память делится на три блока: куча, локальная память и стек. Память, автоматически управляемая JVM, создание и уничтожение объектов приложения и загрузка классов — все это происходит здесь. Локальная память — это специальная память, используемая Java-приложениями. JVM напрямую не управляет своим жизненным циклом, и каждый поток также будет иметь Стек используется для хранения локальных переменных метода, параметров метода и возвращаемых значений, сгенерированных во время работы потока Размер стека по умолчанию, соответствующий каждому потоку, составляет 1M.
Схема управления памятью в Linux и JVM выглядит следующим образом:
Таким образом, с точки зрения памяти для создания потока требуется место в памяти.Если процесс JVM создает поток просто как приложение, а в операционной системе нет оставшейся памяти, выделенной для этого процесса JVM, исключение OOM в будет задан вопрос: невозможно создать новый собственный поток.
Следующая формула может быть использована для расчета максимального количества потоков, которые могут быть созданы с точки зрения памяти:
Максимальное количество потоков = (максимально доступная память операционной системы - память JVM - зарезервированная память операционной системы) / размер стека потоков
По этой формуле мы можем вычислить количество потоков, которые можно создать за счет оставшейся памяти.
Вот результат выполнения команды Linux free, описанной в предыдущем разделе, на производственной машине при возникновении проблемы:
free -m >> /tmp/free.log
total used free shared buffers cached
Mem: 7872 7163 709 0 31 3807-/+ buffers/cache: 3324 4547Swap: 4095 173 3922Tue Jul 5 00:27:51 CST 2016скопировать кодИз приведенного выше вывода можно сделать вывод, что производственная машина имеет 8 ГБ памяти, используется 7 ГБ, а оставшиеся 700 МБ доступны, из которых кэш операционной системы использует 3,8 ГБ. 3,8 ГБ, используемые кешем операционной системы, используются для кэширования данных ввода-вывода.Если памяти процесса недостаточно, эта память может быть освобождена и выделена процессу в первую очередь. Однако нам пока не нужно считать эту память, а оставшиеся 700М пространства можно продолжать использовать для создания количества потоков:
700M / 1M = 700 потоков
Таким образом, в соответствии с расчетом доступной памяти, когда возникает ошибка OOM: невозможно создать новый собственный поток, остается 700 МБ доступной памяти и может быть создано 700 потоков.
Пока можно доказать, что исключение OOM не вызвано тем, что поток поглощает всю память.
Сравнение количества потоков
Как упоминалось выше, есть две конкретные причины для этого исключения.Мы исключили первую причину выше, поэтому давайте начнем со второй причины, чтобы оценить, установила ли операционная система максимальное количество потоков, создаваемых приложением, и оно достигнуто Максимально допустимое количество.
Используйте ulimit -a на рабочей машине, где возникает проблема, чтобы отобразить текущие ограничения различных систем на пользовательские ресурсы:
robert@robert-ubuntu1410：~$ ulimit -acore file size (blocks, -c) 0data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0file size (blocks, -f) unlimited
pending signals (-i) 62819max locked memory (kbytes, -l) 64max memory size (kbytes, -m) unlimited
open files (-n) 65535pipe size (512 bytes, -p) 8POSIX message queues (bytes, -q) 819200real-time priority (-r) 0stack size (kbytes, -s) 10240cpu time (seconds, -t) unlimited
max user processes (-u) 1024virtual memory (kbytes, -v) unlimited
file locks (-x) unlimitedскопировать кодЗдесь мы видим, что максимальное количество пользовательских процессов, разрешенных для использования производственной машиной, составляет 1024:
max user processes (-u) 1024скопировать кодТеперь нам нужно получить поток, созданный пользователем при возникновении проблемы.
Когда возникает проблема, мы используем команду jstack для мониторинга JVM, представленную в предыдущем обзоре, чтобы распечатать ситуацию с потоком Java Пример вывода команды jstack выглядит следующим образом:
robert@robert-ubuntu1410:~$ jstack 27432017-04-09 12:06:51Full thread dump Java HotSpot(TM) Server VM (25.20-b23 mixed mode):"Attach Listener" #23 daemon prio=9 os_prio=0 tid=0xc09adc00 nid=0xb4c waiting on condition [0x00000000]
java.lang.Thread.State: RUNNABLE"http-nio-8080-Acceptor-0" #22 daemon prio=5 os_prio=0 tid=0xc3341000 nid=0xb02 runnable [0xbf1bd000]
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method)
at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:241)
- locked <0xcf8938d8> (a java.lang.Object)
at org.apache.tomcat.util.net.NioEndpoint$Acceptor.run(NioEndpoint.java:688)
at java.lang.Thread.run(Thread.java:745)"http-nio-8080-ClientPoller-1" #21 daemon prio=5 os_prio=0 tid=0xc35bc400 nid=0xb01 runnable [0xbf1fe000]
java.lang.Thread.State: RUNNABLE
at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
- locked <0xcf99b100> (a sun.nio.ch.Util$2)
- locked <0xcf99b0f0> (a java.util.Collections$UnmodifiableSet)
- locked <0xcf99aff8> (a sun.nio.ch.EPollSelectorImpl)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
at org.apache.tomcat.util.net.NioEndpoint$Poller.run(NioEndpoint.java:1052)
at java.lang.Thread.run(Thread.java:745)
......скопировать кодИз вывода команды jstack и статистики мы знаем, что JVM создала в общей сложности 904 потока, но это не достигло максимального предела процесса в 1024.
robert@robert-ubuntu1410:~$ grep "Thread " js.log | wc -l
904скопировать кодЭто наше мнение: в дополнение к потокам прикладного уровня, созданным JVM, могут быть некоторые потоки управления в самой JVM, а также могут быть потоки демона, работающие под пользователем в операционной системе.
Мы продолжаем подсчитывать количество потоков с точки зрения операционной системы.Мы используем команду pstack операционной системы Linux, представленную в сводке выше, и получаем следующий вывод:
PID LWP USER %CPU %MEM CMD 1 1 root 0.0 0.0 /sbin/init 2 2 root 0.0 0.0 [kthreadd] 3 3 root 0.0 0.0 [migration/0] 4 4 root 0.0 0.0 [ksoftirqd/0] 5 5 root 0.0 0.0 [migration/0] 6 6 root 0.0 0.0 [watchdog/0] 7 7 root 0.0 0.0 [migration/1] 8 8 root 0.0 0.0 [migration/1] 9 9 root 0.0 0.0 [ksoftirqd/1] 10 10 root 0.0 0.0 [watchdog/1] 11 11 root 0.0 0.0 [migration/2] 12 12 root 0.0 0.0 [migration/2] 13 13 root 0.0 0.0 [ksoftirqd/2] 14 14 root 0.0 0.0 [watchdog/2] 15 15 root 0.0 0.0 [migration/3] 16 16 root 0.0 0.0 [migration/3] 17 17 root 0.0 0.0 [ksoftirqd/3] 18 18 root 0.0 0.0 [watchdog/3] 19 19 root 0.0 0.0 [events/0] 20 20 root 0.0 0.0 [events/1] 21 21 root 0.0 0.0 [events/2] 22 22 root 0.0 0.0 [events/3] 23 23 root 0.0 0.0 [cgroup] 24 24 root 0.0 0.0 [khelper]
...... 7257 7257 zabbix 0.0 0.0 /usr/local/zabbix/sbin/zabbix_agentd: active checks #2 [idle 1 sec]
7258 7258 zabbix 0.0 0.0 /usr/local/zabbix/sbin/zabbix_agentd: active checks #3 [idle 1 sec]
7259 7259 zabbix 0.0 0.0 /usr/local/zabbix/sbin/zabbix_agentd: active checks #4 [idle 1 sec]
...... 9040 9040 app 0.0 30.5 /apps/prod/jdk1.6.0_24/bin/java -Dnop -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Ddbconfigpath=/apps/dbconfig/ -Djava.io.tmpdir=/apps/data/java-tmpdir -server -Xms2048m -Xmx2048m -XX:PermSize=128m -XX:MaxPermSize=512m -Dcom.sun.management.jmxremote -Djava.rmi.server.hostname=192.168.10.194 -Dcom.sun.management.jmxremote.port=6969 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp -Xshare:off -Dhostname=sjsa-trade04 -Djute.maxbuffer=41943040 -Djava.net.preferIPv4Stack=true -Dfile.encoding=UTF-8 -Dworkdir=/apps/data/tomcat-work -Djava.endorsed.dirs=/apps/product/tomcat-trade/endorsed -classpath commonlib:/apps/product/tomcat-trade/bin/bootstrap.jar:/apps/product/tomcat-trade/bin/tomcat-juli.jar -Dcatalina.base=/apps/product/tomcat-trade -Dcatalina.home=/apps/product/tomcat-trade -Djava.io.tmpdir=/apps/data/tomcat-temp/ org.apache.catalina.startup.Bootstrap start 9040 9041 app 0.0 30.5 /apps/prod/jdk1.6.0_24/bin/java -Dnop -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Ddbconfigpath=/apps/dbconfig/ -Djava.io.tmpdir=/apps/data/java-tmpdir -server -Xms2048m -Xmx2048m -XX:PermSize=128m -XX:MaxPermSize=512m -Dcom.sun.management.jmxremote -Djava.rmi.server.hostname=192.168.10.194 -Dcom.sun.management.jmxremote.port=6969 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp -Xshare:off -Dhostname=sjsa-trade04 -Djute.maxbuffer=41943040 -Djava.net.preferIPv4Stack=true -Dfile.encoding=UTF-8 -Dworkdir=/apps/data/tomcat-work -Djava.endorsed.dirs=/apps/product/tomcat-trade/endorsed -classpath commonlib:/apps/product/tomcat-trade/bin/bootstrap.jar:/apps/product/tomcat-trade/bin/tomcat-juli.jar -Dcatalina.base=/apps/product/tomcat-trade -Dcatalina.home=/apps/product/tomcat-trade -Djava.io.tmpdir=/apps/data/tomcat-temp/ org.apache.catalina.startup.Bootstrap start
......скопировать кодКоличество потоков, созданных под пользователем, составляет 1021 с помощью команды.
$ grep app pthreads.log | wc -l
1021скопировать кодТеперь мы определили, что число 1021 довольно близко к максимальному количеству процессов 1021. Как мы упоминали ранее, в операционной системе Linux потоки реализуются через облегченные процессы, поэтому для ограничения максимального количества процессов для пользователей , Это должно ограничить максимальное количество потоков пользователя.Что касается того, почему об исключении было сообщено, точно не достигнув максимального значения 1024, это должна быть функция самозащиты системы.Исходя из того, что все еще есть Осталось 3 темы, будет сообщено об ошибке.
Пока мы нашли причину проблемы с помощью анализа, но мы до сих пор не знаем, почему создается так много потоков.Из первого вывода мы знаем, что JVM создала 907 потоков приложения, поэтому все они находятся в том, что сделать?
Поэтому, когда возникает проблема, мы используем команду jstack JVM для проверки вывода и знаем, что каждый поток блокируется оператором, который печатает журнал, Код для печати журнала в log4j реализован следующим образом:
public void callAppenders(LoggingEvent event) { int writes = 0; for(Category c = this; c != null; c=c.parent) { // Protected against simultaneous call to addAppender, removeAppender,...
synchronized(c) { if(c.aai != null) {
writes += c.aai.appendLoopOnAppenders(event);
} if(!c.additive) { break;
}
}
} if(writes == 0) {
repository.emitNoAppenderWarning(this);
}
}скопировать кодВ log4j журнал печати имеет блокировку.Функция блокировки состоит в том, чтобы разрешить сериализацию журнала печати и обеспечить правильность и последовательность журнала в файле журнала.
Итак, снова возникает новый вопрос: почему блокировка журнала печати происходит только в 0:00 утра, а иногда и в другое время? На этот раз мы возвращаемся к идее проблемы с новыми подсказками.Нет запланированной задачи для приложения на 12:00 утра.Будут ли в системе другие задачи с интенсивным вводом-выводом, такие как архивирование журналов, диск резервное копирование и т.д.?
После встречи с отделом эксплуатации и технического обслуживания в основном было установлено, что резка журнала в 0:00 каждый день приводит к занятию дискового ввода-вывода, поэтому печать журнала блокируется.Журнал необходим для каждой рабочей задачи.Если log заблокирован, пул потоков заблокирован, а пул потоков заблокирован.Если пул потоков увеличен, если количество потоков в пуле потоков превышает 1024, будет сообщено об ошибке.
На данный момент мы в основном определили причину проблемы, но нам все еще нужно проанализировать и продемонстрировать увеличение IO, вызванное рубкой бревен.
Во-первых, мы используем vmstat, представленный в предыдущем обзоре, для просмотра данных ожидания ввода-вывода при возникновении проблемы:
vmstat 2 1 >> /tmp/vm.log
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st 3 0 177608 725636 31856 3899144 0 0 2 10 0 0 39 1 1 59 0 Tue Jul 5 00:27:51 CST 2016скопировать кодВидно, что при возникновении проблемы ожидание ввода-вывода ЦП составляет 59%, и в то же время оно проверяется коллегами в отделе эксплуатации и обслуживания.Коллеги по эксплуатации и обслуживанию подтверждают, что скрипт прорезан через кота Командный метод, сначала cat лог-файл, а потом по конвейеру распечатать его в другой файл, а затем очистить исходный файл, следовательно, это однозначно приведет к увеличению IO.
На самом деле в процессе проблемы еще есть сомнение.Мы думаем что поток блокируется IO, а пул потоков открывается, в результате чего потоки увеличиваются.Поэтому мы проверили настройки потока Tomcat pool, и мы обнаружили, что пул потоков Tomcat установлен на 800. Само собой разумеется, что он никогда не превысит 1024.
<Connector port="8080"
maxThreads="800" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" redirectPort="8443" acceptCount="100"
debug="0" connectionTimeout="20000"
disableUploadTimeout="true" />скопировать кодКлючевым моментом является то, что в сервис-ориентированной архитектуре платежной платформы, на которой находится автор, используются два набора сервис-ориентированных фреймворков, один — на основе даббо, а другой — двухточечный RPC. , который используется для снижения качества использования службы dubbo в случае чрезвычайной ситуации.
Каждая служба настроена на службу RPC «точка-точка» и имеет эксклюзивный пул потоков:
<Connector port="8090"
maxThreads="800" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" redirectPort="8443" acceptCount="100"
debug="0" connectionTimeout="20000"
disableUploadTimeout="true" />скопировать кодПоскольку мы разработали принцип автоматического перехода на более раннюю версию при настройке инфраструктуры службы dubbo, если нагрузка на службу dubbo становится высокой, она автоматически переключается на структуру RPC «точка-точка», что также соответствует принципу аварийного переключения микросервисов, но не проводится в проекте.Всестороннее рассмотрение, как только некоторые сервисы переключаются на RPC «точка-точка», а некоторые сервисы не переключаются, два локальных пула заполняются, поэтому лимит в 1024 превышен, и есть это проблема.
На данный момент мы можем в основном убедиться, что основная причина проблемы заключается в том, что обрезка журнала приводит к увеличению нагрузки ввода-вывода, затем блокирует пул потоков и, наконец, происходит OOM: отключить для создания нового собственного потока.
Оставшаяся задача — свести к минимуму повторяющуюся проблему и проверить причину проблемы на практике. Мы связались с отделом стресс-тестирования производительности и предложили требования к стресс-тестированию:
Максимальная настройка пула потоков Tomcat — 1500.
Максимальное количество пользовательских процессов, разрешенное операционной системой, равно 1024.
В процессе нагнетания сервиса необходимо вручную создать занятую операцию ввода-вывода, а ожидание ввода-вывода должно быть не ниже 50%.
После дня напряженной работы отдела испытаний под давлением среда была урегулирована, и оказалось, что эту проблему можно воспроизвести полностью.
Наконец, обсудите и просмотрите все соответствующие отделы, примените решение, и оно включает:
Все приложения изменены, чтобы сократиться по часам или напрямую использовать функцию прокатки журналов log4j.
Количество потоков в пуле потоков Tomcat необоснованно установлено с количеством потоков в операционной системе, поэтому соответствующим образом уменьшите количество потоков в пуле потоков Tomcat.
Чтобы обновить журналы log4j, используйте logback или log4j2.
Проблема OOM на этот раз может быть связана с "несколькими причинами, многочисленными следствиями, несколькими машинами, несколькими сервисными пулами и разным временем". Чтобы решить эту проблему, я усердно работал с коллегами из отдела эксплуатации и обслуживания, отдела мониторинга и отдел измерения стресса производительности.После нескольких дней и ночей я, наконец, собрал информацию в Интернете, проанализировал проблему и с помощью коллег из отдела стресс-тестирования производительности свел к минимуму повторение проблемы и нашел основную причину проблемы.Наконец-то , было предложено эффективное решение основной причины проблемы.
3. Скрипты, написанные на месте с коллегами по мониторингу
Этот раздел предоставляет автору простой сценарий для решения проблемы OOM в процессе практики. Этот сценарий временно записывается на проблемной машине для решения проблемы OOM (невозможность создания собственного потока) и временно используется. не написано.Это очень профессионально, и автор не оптимизировал его, чтобы сохранить оригинальный стиль, чтобы читатели могли чувствовать, что они находятся на сцене, просто чтобы получить необходимую информацию и решить проблему, но когда онлайн-проблема очень срочно, этот сценарий будет очень полезен.
#!/bin/bashps -Leo pid,lwp,user,pcpu,pmem,cmd >> /tmp/pthreads.logecho "ps -Leo pid,lwp,user,pcpu,pmem,cmd >> /tmp/pthreads.log" >> /tmp/pthreads.logecho `date` >> /tmp/pthreads.logecho 1pid=`ps aux|grep tomcat|grep cwh|awk -F ' ' '{print $2}'`echo 2echo "pstack $pid >> /tmp/pstack.log" >> /tmp/pstack.log
pstack $pid >> /tmp/pstack.logecho `date` >> /tmp/pstack.logecho 3echo "lsof >> /tmp/sys-o-files.log" >> /tmp/sys-o-files.log
lsof >> /tmp/sys-o-files.logecho `date` >> /tmp/sys-o-files.logecho 4echo "lsof -p $pid >> /tmp/service-o-files.log" >> /tmp/service-o-files.log
lsof -p $pid >> /tmp/service-o-files.logecho `date` >> /tmp/service-o-files.logecho 5echo "jstack -l $pid >> /tmp/js.log" >> /tmp/js.log
jstack -l -F $pid >> /tmp/js.logecho `date` >> /tmp/js.logecho 6 echo "free -m >> /tmp/free.log" >> /tmp/free.log
free -m >> /tmp/free.logecho `date` >> /tmp/free.logecho 7echo "vmstat 2 1 >> /tmp/vm.log" >> /tmp/vm.log
vmstat 2 1 >> /tmp/vm.logecho `date` >> /tmp/vm.logecho 8echo "jmap -dump:format=b,file=/tmp/heap.hprof 2743" >> /tmp/jmap.log
jmap -dump:format=b,file=/tmp/heap.hprof >> /tmp/jmap.logecho `date` >> /tmp/jmap.logecho 9echo endскопировать кодЕсли читатели сталкивались с проблемами OOM в Интернете, они могут следовать идее этого, казалось бы, простого, но богатого информацией сценария мониторинга службы Java, и использовать различные сценарии и команды, представленные в этой статье, для поиска основной причины проблемы. .
Для выдающихся талантов нет недостатка в возможностях трудоустройства, для них есть только хорошие возможности. Но у них часто нет энергии, чтобы найти наилучший вариант среди множества возможностей. 100offerТаланты и компании на платформе будут строго проверяться, чтобы «лучшие таланты» и «лучшие компании» могли встретиться. Отсканируйте приведенный ниже QR-код, подпишитесь на 100offer и расскажите о своих ожиданиях от следующей работы. В течение недели получите 5-10 отличных возможностей для удовлетворения ваших требований!