Я действительно замечал это примечание в странице справочника для date
.
DATE STRING
The --date=STRING is a mostly free format human readable date string
such as "Sun, 29 Feb 2004 16:21:42 -0800" or "2004-02-29
16:21:42" or even "next Thursday". A date string may contain
items indicating calendar date, time of day, time zone, day of
week, relative time, relative date, and numbers. An empty string
indicates the beginning of the day. The date string format
is more complex than is easily documented here but is fully described
in the info documentation.
Это не окончательно, но это явно не показывает строку формата времени, которая включает T
поскольку Вы пытаетесь для [ISO 8601]. Как @Gilles обозначенный ответ, поддержка ISO 8601 в GNU CoreUtils является относительно новой.
Можно использовать Perl для переформулирования строки.
Пример:
$ date -d "$(perl -pe 's/(.*)T(\d{2})(\d{2})(\d{2})/$1 $2:$3:$4/' \
<<<"20140103T142233")"
Fri Jan 3 14:22:33 EST 2014
Можно сделать этот дескриптор обеими строками, которые включают секунды и тех, которые не делают.
20140103T1422:
$ date -d "$(perl -pe 's/^(.*)T(\d{2})(\d{2})(\d{2})$/$1 $2:$3:$4/ || \
s/^(.*)T(\d{2})(\d{2})$/$1 $2:$3:00/' <<<"20140103T1422")"
Fri Jan 3 14:22:00 EST 2014
20140103T142233:
$ date -d "$(perl -pe 's/^(.*)T(\d{2})(\d{2})(\d{2})$/$1 $2:$3:$4/ || \
s/^(.*)T(\d{2})(\d{2})$/$1 $2:$3:00/' <<<"20140103T142233")"
Fri Jan 3 14:22:33 EST 2014
Если сложить MEM%
для всех одинаково выглядящих хромовых процессов, то у вас более 100%, что невозможно. Это потому, что это не отдельные процессы, а потоки , которые занимают одно и то же пространство памяти. htop
показывает их по умолчанию, но смотрите здесь , как это изменить и получить представление, которое будет иметь больший смысл для вас.
Ваша общая используемая оперативная память составляет 1047 из 1727 МБ, поэтому у вас нет проблем с памятью. Глядя на статистику памяти, помните, что виртуальная память, более правильно: виртуальное адресное пространство , показанное здесь, как VIRT
не является реальной памятью . Это адресное пространство , и большинство адресов не используются и ничему не соответствуют. На linux, размер этого притворного пространства может быть до 4 Гб на процесс, даже если у вас не так много доступной памяти для начала.
Приличной метрикой фактически используемого объема оперативной памяти является размер RSS или резидентной памяти (в случае htop
, RES
). Если убрать потоки из вида, то можно увидеть, что на самом деле существует только один процесс Google-chrome google-chrome
объемом 142 MB (на самом деле может существовать несколько по-настоящему отдельных процессов хромирования, но не десятки). Еще одна важная статистика при диагностике проблем с производительностью системы - это количество процессорного времени (TIME+
), но опять же ничего особенно не выглядит здесь WRT-хромом.
Я использую Chromium, и у меня такая же проблема: Chromium занимает много памяти, зависает система. Проблема не в потреблении памяти , а в моем пользовательском опыте: Мне очень не нравится, когда мой ноутбук превращается в кирпич .
Есть открытая проблема с хромом, и сегодня она все еще не решена: https://bugs.chromium.org/p/chromium/issues/detail?id=393395
Я использую Linux Mint, поэтому тестирую несколько решений:
ulimit
. У меня не работает ... cgroup
: добавьте браузер в группу процессов и установите ограничения: https://gist.github.com/juanje/9861623