Добрый день.

На сервер наблюдаются странные проблемы с перформенсом, в /var/log/syslog вижу (копипаста непрерывного куска лога):

Jan 25 14:39:09 *** kernel: [12275401.439301] net_ratelimit: 1 callbacks suppressed
Jan 25 14:39:18 *** kernel: [12275409.568890] net_ratelimit: 18 callbacks suppressed
Jan 25 14:39:23 *** kernel: [12275414.714950] net_ratelimit: 49 callbacks suppressed
Jan 25 14:39:39 *** kernel: [12275431.356811] net_ratelimit: 20 callbacks suppressed
Jan 25 14:39:44 *** kernel: [12275436.465029] net_ratelimit: 19 callbacks suppressed
Jan 25 14:39:50 *** kernel: [12275442.526348] net_ratelimit: 7 callbacks suppressed
Jan 25 14:39:56 *** kernel: [12275447.619611] net_ratelimit: 37 callbacks suppressed
Jan 25 14:40:01 *** kernel: [12275453.009875] net_ratelimit: 7 callbacks suppressed

В настроках ярда по выдаче сообщений от сетевого стека стоит 10 сообщений в 5 секунд:

/proc/sys/net/core$ tail message_*
==> message_burst <==
10

==> message_cost <==
5

Почему я не вижу 10 сообщений с ошибками + надпись «N callbacks suppressed», а только сообщения о достижении лимита сообщений в секунду? Я где-то что-то недонастроил? Или я неправильно понимаю смысл /proc/sys/net/core/message_{burst,cost}?

дистр: Ubuntu 12.04.5

ядро: 3.13.0-57-generic #95~precise1-Ubuntu SMP Mon Jun 22 09:43:07 UTC 2015

Ubuntu 14.10

На корпусе стоит 3х пиновый вентилятор и сильно шумит. Мать asus p8z77-i deluxe имеет чип мониторинга nuvoton nct6779d который отлично работает с lm_sensors:

$ sensors | grep fan
fan1:                  2170 RPM  (min =    0 RPM)
fan2:                   484 RPM  (min =    0 RPM)
fan5:                     0 RPM  (min =    0 RPM)

Я правильно понимаю, что через ACPI могу попросить мать сделать power on/off на этот вентилятор? Поставил пакет acpi, порылся в /sys/class, ничего не понял. Подскажите, пожалуйста, что читать и куда смотреть?

$ acpi -c
Cooling 0: LCD 0 of 20
Cooling 1: x86_pkg_temp no state information available
Cooling 2: intel_powerclamp no state information available
Cooling 3: Processor 0 of 3
Cooling 4: Processor 0 of 3
Cooling 5: Processor 0 of 3
Cooling 6: Processor 0 of 3
Cooling 7: Fan 1 of 1
Cooling 8: Fan 1 of 1
Cooling 9: Fan 1 of 1
Cooling 10: Fan 0 of 1
Cooling 11: Fan 0 of 1

$ dmesg | grep -i fan
[    0.493511] ACPI: Fan [FAN0] (off)
[    0.493539] ACPI: Fan [FAN1] (off)
[    0.493566] ACPI: Fan [FAN2] (off)
[    0.493592] ACPI: Fan [FAN3] (off)
[    0.493618] ACPI: Fan [FAN4] (off)

Заранее прошу прощения, скорее всего вопрос задавался, но я ничего не нашел на первых страницах выдачи «site:linux.org.ru docker». Я познакомился с этой тулзенью пару дней назад, возможно, немного не понимаю ключевых концепций, лежащих в ее основе. Так что мой вопрос может быть странным. Дисклеймер закончился.

Я не понимаю, как предлагается использовать докер в цикле разработки приложения. Предположим:

1. Я пишу программу на языке А. У меня есть код + мейкфайл.
2. Я создаю «базовый» контейнер:
---Dockerfile---
FROM ubuntu
RUN apt-get install super-compiler-for-lang-A
------
$ docker build -t base_image .

3. Далее, для сборки своего приложения я делаю следующие:
---Dockerfile---
FROM base_image
ADD ./src /home/app/src
RUN /home/app/src/build_my_app.sh
------
$docker build -t temp .

4. Приложение собрано в имедж temp, я могу проверить его создав контейнер и как-то дернув за приложение:
$ docker run -i -t temp /bin/bash
$ /home/app/release/test_my_app.sh

Собственно здесь начинаются непонятки. Предположим, я добавил функциональности. Теперь мне надо делать:

$docker build -t temp2 .

что повлечет за собой пересборку приложения? Но зачем мне заново перезаливать исходники и заново пересобирать, если у меня изменения только в 1 модуле?

В общем не совсем понятна модель использования при частых пересборках софта. Прошу прощения за неровный почерк.

Есть большая огромная программа, собранная с отладкой. Хочу знать, какие библиотечные вызовы происходят в определенный момент работы.

ltrace по какой-то причине не работает, да и если бы работал, то не помог, т.к. чтобы дойти до необходимого момента пришлось бы промотать километры ltrace-лога - инициализация, загрузка различной фигни и пр.

сейчас делаю так:

gdb application
> rbreak gtk_.*
...
> commands
> silent
> bt 1
> continue
> end

но данный подход выбирает только GTK-вызовы, а мне нужны вообще все. Тыкать по библиотекам мне надоело.

rbreak .* вызывает расход памяти овер 4 Гб и gdb сигфолится.

Каюсь, Debugging with GDB не читал полностью, только листал. Хотеть рецепт из вашей поваренной книги. Торжественно обещаю прочитать Debugging with GDB на выходных.

Легкий улучшайзинг осома:

• тема zenburn
• обоина, котору почти никогда не вижу :)
• vicious виджеты (которые не двигают tasklist при увеличении отображаемого значения!!11 string.format(«%3d»,..) же)
• шрифт кончено же terminus (в гуевых приложениях DejaVu Sans вроде)
• выкинуты ненужные кнопочки, лейауты и шоткаты.
• kbdd + индикация переключения через naughty c вики (немного подлатал ее)

>>> Просмотр (1280x1024, 737 Kb)