Другой способ с tr
+sed
:
tr -s \\n <infile | sed '$!G;s/Question Nr.*/\\item/'
tr
сжимает все новые строки, а затем sed
добавляет содержимое пробела (пустую новую строку) к каждой строке, кроме последней, заменяя Question Nr. *
на \item
. С помощью этого метода вы не сможете редактировать файл на месте. Я выбрал tr
, так как он быстрее, чем sed
's regex (даже если он не такой чистый, как sed
-only solution)
Ваши файловые системы devtmpfs
и tmpfs
на самом деле не используют гигабайты памяти; потенциально они могут вырасти до 32 ГБ, однако этот размер является лишь верхним пределом их роста. Этот верхний предел также настраивается, и они не используют его; они съедают только ту часть оперативной памяти, где у них есть содержимое.
Если вы посмотрите прямо в свой df:/dev
использует менее 1M и поэтому отображается как 0, /dev/shm
то же самое, /sys/fs/cgroup
та же ситуация, /tmp
использует 17 МБ, /run
использует 49 МБ.
Таким образом, объединенные файловые системы devtmpfs и tmpfs используют менее 70 МБ оперативной памяти. (мегабайт, заметьте)
Что бы ни поглощало вашу оперативную память, это явно не те файловые системы.
Как я уже сказал, вы можете изменить их верхние предельные значения, если это вас беспокоит, однако на данный момент я хотел бы сосредоточиться на том, сколько оперативной памяти настроено для использования вашими параметрами JVM.
В конечном счете, в соответствии с отзывом ОП,были проблемы с раздуванием памяти от хоста vmware и были ошибки в dmesg, упоминающие работу vmballoon _.
Это вместе с квотой 8 ГБ в гипервизоре ВМ привело к сообщениям о странном поведении, при котором загрузка ВМ была хаотичной, поэтому было действительно подтверждено, что эти файловые системы не были виновниками.