DZ
локи едят cpu при конфликтах
Не должны.
Возможно, ты видишь busy_wait.
Покажи msacc за 2 секунды.
Возможно, ты видишь busy_wait.
Покажи msacc за 2 секунды.
Не должны.
Возможно, ты видишь busy_wait.
Покажи msacc за 2 секунды.
Size: a a a
2020 October 22
PK
busy_wait выключен
DZ
busy_wait выключен
В смысле выключен? Как?
PK
В смысле выключен? Как?
+sbwt none
PK
Не должны.
Возможно, ты видишь busy_wait.
Покажи msacc за 2 секунды.
Возможно, ты видишь busy_wait.
Покажи msacc за 2 секунды.
за 2 секунды под рукой нет, только 10
(khub@127.0.0.1)2> msacc:start(10000), msacc:print().
Average thread real-time : 10001029 us
Accumulated system run-time : 27038322 us
Average scheduler run-time : 3339088 us
Thread alloc aux bifbusy_wait check_io emulator ets gc gc_full nif other port send sleep timers
Stats per type:
async 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 100.00% 0.00%
aux 0.00% 0.01% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 99.99% 0.00%
dirty_cpu_sche 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 99.99% 0.00%
dirty_io_sched 0.00% 0.00% 0.00% 0.01% 0.00% 0.00% 0.00% 0.00% 0.00% 0.01% 0.00% 0.00% 0.00% 99.99% 0.00%
poll 0.19% 0.00% 0.00% 0.00% 2.86% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 96.95% 0.00%
scheduler 3.51% 1.62% 7.30% 0.28% 0.78% 2.43% 4.00% 2.22% 0.16% 5.28% 1.71% 3.14% 0.89% 66.61% 0.06%
scheduler 4.62% 2.19% 9.85% 0.34% 1.00% 3.27% 1.26% 2.65% 0.19% 4.23% 2.33% 4.14% 1.19% 62.66% 0.09%
DZ
за 2 секунды под рукой нет, только 10
(khub@127.0.0.1)2> msacc:start(10000), msacc:print().
Average thread real-time : 10001029 us
Accumulated system run-time : 27038322 us
Average scheduler run-time : 3339088 us
Thread alloc aux bifbusy_wait check_io emulator ets gc gc_full nif other port send sleep timers
Stats per type:
async 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 100.00% 0.00%
aux 0.00% 0.01% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 99.99% 0.00%
dirty_cpu_sche 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 99.99% 0.00%
dirty_io_sched 0.00% 0.00% 0.00% 0.01% 0.00% 0.00% 0.00% 0.00% 0.00% 0.01% 0.00% 0.00% 0.00% 99.99% 0.00%
poll 0.19% 0.00% 0.00% 0.00% 2.86% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 96.95% 0.00%
scheduler 3.51% 1.62% 7.30% 0.28% 0.78% 2.43% 4.00% 2.22% 0.16% 5.28% 1.71% 3.14% 0.89% 66.61% 0.06%
scheduler 4.62% 2.19% 9.85% 0.34% 1.00% 3.27% 1.26% 2.65% 0.19% 4.23% 2.33% 4.14% 1.19% 62.66% 0.09%
sleep 60%+ — всё у тебя более-менне охуенно (лишь bif подозрительно большой), я не понимаю, на что ты жалуешься.
PK
sleep 60%+ — всё у тебя более-менне охуенно (лишь bif подозрительно большой), я не понимаю, на что ты жалуешься.
просто трафика в этот момент не было
вопрос в том, что потребление cpu на запрос высокое
и уменьшение кол-ва шедулеров этот момент меняет заметно (при уменьшении с 14и до 4х потребление cpu на запрос падает примерно на 20%)
вопрос в том, что потребление cpu на запрос высокое
и уменьшение кол-ва шедулеров этот момент меняет заметно (при уменьшении с 14и до 4х потребление cpu на запрос падает примерно на 20%)
DZ
просто трафика в этот момент не было
вопрос в том, что потребление cpu на запрос высокое
и уменьшение кол-ва шедулеров этот момент меняет заметно (при уменьшении с 14и до 4х потребление cpu на запрос падает примерно на 20%)
вопрос в том, что потребление cpu на запрос высокое
и уменьшение кол-ва шедулеров этот момент меняет заметно (при уменьшении с 14и до 4х потребление cpu на запрос падает примерно на 20%)
Пётр. Ты говоришь сейчас вещи, которые мне кажутся взаимоисключающими:
* обработка запроса дорогая
* вот данные с простаивающей системы
* обработка запроса дорогая
* вот данные с простаивающей системы
PK
Пётр. Ты говоришь сейчас вещи, которые мне кажутся взаимоисключающими:
* обработка запроса дорогая
* вот данные с простаивающей системы
* обработка запроса дорогая
* вот данные с простаивающей системы
ладно, забей :)
jc
а как лапшин говорил что шедулер резервировать на это кпу не жрется?
jc
там нет картины что все кпу загружены на максимум при таком подходе?
ИИ
там нет картины что все кпу загружены на максимум при таком подходе?
если все кпу загружены ровно под завязку значит ерланг норм справляется со своей задачей
ИИ
но вообще понятно что переключение шедулера с кпу на кпу это потеря ресурсов и да можно ограничить число шедулеров + прибить к кпу
DZ
просто трафика в этот момент не было
вопрос в том, что потребление cpu на запрос высокое
и уменьшение кол-ва шедулеров этот момент меняет заметно (при уменьшении с 14и до 4х потребление cpu на запрос падает примерно на 20%)
вопрос в том, что потребление cpu на запрос высокое
и уменьшение кол-ва шедулеров этот момент меняет заметно (при уменьшении с 14и до 4х потребление cpu на запрос падает примерно на 20%)
давай ещё вот какие две вещи разделим:
* потребление процессора согласно инструментам операционной системы
* утилизация шедулеров (
И если заботиться о приложении, то важно, что с шедулерами, а если заботиться о чём-то ещё, работающем на том же сервере, то там ещё масса вопросов
* потребление процессора согласно инструментам операционной системы
* утилизация шедулеров (
erlang:statistics(scheduler_wall_time_all))И если заботиться о приложении, то важно, что с шедулерами, а если заботиться о чём-то ещё, работающем на том же сервере, то там ещё масса вопросов
ML
давай ещё вот какие две вещи разделим:
* потребление процессора согласно инструментам операционной системы
* утилизация шедулеров (
И если заботиться о приложении, то важно, что с шедулерами, а если заботиться о чём-то ещё, работающем на том же сервере, то там ещё масса вопросов
* потребление процессора согласно инструментам операционной системы
* утилизация шедулеров (
erlang:statistics(scheduler_wall_time_all))И если заботиться о приложении, то важно, что с шедулерами, а если заботиться о чём-то ещё, работающем на том же сервере, то там ещё масса вопросов
> а если заботиться о чём-то ещё, работающем на том же сервере, то там ещё масса вопросов
у которых одно верное решение =)
у которых одно верное решение =)
DZ
> а если заботиться о чём-то ещё, работающем на том же сервере, то там ещё масса вопросов
у которых одно верное решение =)
у которых одно верное решение =)
в нашей области — да
jc
уносить на другой сервер
DZ
давай ещё вот какие две вещи разделим:
* потребление процессора согласно инструментам операционной системы
* утилизация шедулеров (
И если заботиться о приложении, то важно, что с шедулерами, а если заботиться о чём-то ещё, работающем на том же сервере, то там ещё масса вопросов
* потребление процессора согласно инструментам операционной системы
* утилизация шедулеров (
erlang:statistics(scheduler_wall_time_all))И если заботиться о приложении, то важно, что с шедулерами, а если заботиться о чём-то ещё, работающем на том же сервере, то там ещё масса вопросов
про шедулеры поясню.
Там возвращается такая штука:
второе число — сколько шедулер был занят делом, а третье — вообще часы шедулера.
Соответственно, если за секунду второе число выросло на столько же, насколько и третье — шедулер плотно чем-то занят.
Если в любой момент есть шедулер с неиспользованным временем, то приложению должно быть збс.
Связанная метрика —
Там возвращается такая штука:
12> erlang:statistics(scheduler_wall_time_all).
[{1,217000,38687694000},
{4,150000,38687692000},
{2,190000,38687661000},
{3,8564000,38687694000},
...
второе число — сколько шедулер был занят делом, а третье — вообще часы шедулера.
Соответственно, если за секунду второе число выросло на столько же, насколько и третье — шедулер плотно чем-то занят.
Если в любой момент есть шедулер с неиспользованным временем, то приложению должно быть збс.
Связанная метрика —
statistics(total_run_queue_lengths_all) и вокруг неё. Если там 0 примерно всегда — приложению збсAB
apt install -y build-essential crossbuild-essential-armhf
./otp_build autoconf --host=arm-linux-gnueabihf --build=x86_64-linux-gnu
./configure --enable-bootstrap-only --disable-pgo --without-threadnames
# тут фигня написана
# http://erlang.org/pipermail/erlang-questions/2014-April/078459.html
# тут дело: http://erlang.org/doc/installation_guide/INSTALL-CROSS.html
make -j 5 bootstrap
# а потом уже основной код:
./configure --host=arm-linux-gnueabihf --build=x86_64-linux-gnu --enable-smp-support \
--enable-dynamic-ssl-lib --enable-builtin-zlib \
--without-megaco --without-wx --without-et --without-diameter --without-eldap \
--without-debugger --without-mnesia \
--without-odbc --without-jinterface \
--disable-pgo \
--enable-kernel-poll --without-java --enable-dirty-schedulers $SSL_ERL_FLAGS \
--enable-lock-counter $EXTRAOPTS
спасибо большое, попробую!
AP
про шедулеры поясню.
Там возвращается такая штука:
второе число — сколько шедулер был занят делом, а третье — вообще часы шедулера.
Соответственно, если за секунду второе число выросло на столько же, насколько и третье — шедулер плотно чем-то занят.
Если в любой момент есть шедулер с неиспользованным временем, то приложению должно быть збс.
Связанная метрика —
Там возвращается такая штука:
12> erlang:statistics(scheduler_wall_time_all).
[{1,217000,38687694000},
{4,150000,38687692000},
{2,190000,38687661000},
{3,8564000,38687694000},
...
второе число — сколько шедулер был занят делом, а третье — вообще часы шедулера.
Соответственно, если за секунду второе число выросло на столько же, насколько и третье — шедулер плотно чем-то занят.
Если в любой момент есть шедулер с неиспользованным временем, то приложению должно быть збс.
Связанная метрика —
statistics(total_run_queue_lengths_all) и вокруг неё. Если там 0 примерно всегда — приложению збсВ новом erts есть scheduler он чуть более прост чем erlang:statistics