• Как пожаловаться на противоречащий сам себе вопрос?

    vabka
    @vabka
    Токсичный шарпист
    Если кажется, что вопрошающий хочет чего-то невозможного, то следует написать об этом в ответе или в комментарии и предложить альтернативу, выяснив, для чего это нужно.
    Ответ написан
    Комментировать
  • Ошибка при использовании grep на сервере?

    Adamos
    @Adamos
    grep -R "Вечность" /dev/urandom
    grep, начиная с корня системы

    Не начинайте с корня, начинайте с тех мест, где реально надо искать. В корне куча виртуальных папок, примонтированные шары, блочные устройства... не надо в нем запускать команды с -R. Вообще не надо.
    Ответ написан
    5 комментариев
  • Intel Pentium 4 478 socket 3.4Ггц?

    pindschik
    @pindschik
    ФЫВА ОЛДЖ
    Не поддерживает ряд инструкций, необходимых современным версиям браузеров для работы.
    И комп, в котором он стоит, наверняка не поддерживает аппаратное декодирование H264 - соответственно все видео в браузерах - становятся софтовыми. А софтовой производительностью у него совсем не ахти. Сильно меньше чем у Core 2, чем у Core 1-го поколения (был и такой), его предшественника Pentium Mobile и даже их прародителя - Pentium III Tualatin... И это несмотря на хорошие частоты.

    Но в варианте "цифрового коня в ваккуме", да он может. Вопрос нюансов на практике.
    Ответ написан
    1 комментарий
  • Почему после запуска контейнера к нему нельзя подключиться в браузере?

    @Drno
    Потому что докер это как бы отдельная "ОС", и там свой личный локалхост...
    Ответ написан
    1 комментарий
  • Context switch per second (Linux) 1.3млн это много или мало?

    saboteur_kiev
    @saboteur_kiev Куратор тега Linux
    software engineer
    Нужно понимать как работает многозадачность и распределение процессорного времени по ядрам.
    В Линукс довольно сложно посчитать реальную занятость процессора.
    В сам свитчинг ничего упираться не может, точнее нет каких-то специальных лимитов. Это обычная процессорная занятость, относящаяся наверное к system cpu usage, но это неточно. Чем быстрее процессор, тем быстрее он может выполнять свитчинг и тем больше свитчингов в секунду может быть выполнено, это просто выполнение инструкций процессора вне рамках процессов, а внутри ядра системы, точнее process scheduler.

    Но проблема в том, как именно распределяется процессорное время. process scheduler в ядре линукса выделяет слайсы примерно по 10-15 милисекунд на процесс, потом переключает на другой. Для процессов, которые что-то активно вычисляют (например архивация), после анализа деятельности может быть выделен более длинный слайс или несколько подряд, то есть уменьшается свитчинг. При этом оценка времени, которая нужна на сам свитчинг - она довольно сложная, ведь для подсчета количество потраченного cpu нужно потратить cpu, и эти 10-15% может на самом деле не существовать.

    Если парралельных процессов очень много и все хотят что-то делать (чекнуть load average), то машина просто не успевает обработать их все, и тратить на переключение приличное количество ресурса, вместо того чтобы непосредственно выполнять код ваших программ.
    Таким образом какого-то определенного лимита на context switching нет, это просто еще одна метрика, которая может подсказать что слишком много одновременно запускаете, можно попробовать оптимизировать.

    Ну или просто не хватает CPU, а система ошибочно показывает свободные ресурсы, которых на самом деле нет.

    Линукс на самом деле не так уж детально может посчитать точное количество ресурсов. Там выполняется все очень просто - на входе в контекст засекается timestamp, на выходе из контекста засекается таймстамп, и потраченное время дописывается в метаданные процесса (для каждого ядра, если процесс многопоточный). Исторические значения не записываются, в метаданных процесса есть только вот это - сколько всего cpu usage с момента старта процесса.
    Если запустить какой-нить top, он будет каждые 1-2 секунды бегать по списку процессов, сравнивать этот параметр и показывать результат загруженности за последние 1-2 секунды, но вот уточнить процесс занял свои 25% cpu плавно в течение секунды, или он занимал 100% cpu первую четверть секунды или третью - вы уже не сможете.

    Ну и само ядро считает свои внутренние потоки так же само.
    И только активность самого process scheduler (то есть cpu затраченное на анализ и переключения процессов) не может быть красиво подсчитана.

    p.s. я не разработчик линукс, поэтому это мое IMHO основанное на наблюдениях и обзорных статьях о работе современного планировщика, если будут гуру которые меня поправят или подтвердят сказанное - будет круто.
    Ответ написан
    Комментировать