I love Poettering .. :-)

Меня интересует раскладывание в кошерную структуру message, иначе никакого профита от новой структуры нет.

Ну-ну, фильтровать по datetime или source чтобы в десятки-тысячи раз сэкономить процессорное время, диск и память это не профит? А еще syslog знает про level.

Конечно с условиями.

Ты специально выбрал единственно возможный пример где от БД нет никакой пользы? Твой пример НИЧЕМ не отличается от банального грепанья. like всегда был тормозом и будет им по определению. Добавив более формальные условия которые известны в 99% случаев экономия конечно будет.

not_sure_if_trolling_or_just_stupid.jpg

Lumberjack — новый совместный проект создателей rsyslog, syslog-ng и journald

Lumberjack — новый совместный проект создателей rsyslog, syslog-ng и journald

Спасибо. Сплошной ад и израиль. Конечно запросы условно говоря можно будет делать с бэкендом типа xml или json, на практике же для независимости от размера логов можно будет использовать исключительно убогие потоковые парсеры. База данных уже лучше, но смотрю я на захардкоженый список полей и очень расстраиваюсь. Вот кто мешал сделать кастомные поля вместо монстрообразного списка?

ждем новости: journal будет использовать sqlite как основной backend. Леннарт уже написал несколько патчей для нее, которые несовместимы с upstream. В следующем релизе федора будет использоватся скулатот поттернига

s/скулатот/скулайт/

фильтровать по datetime или source чтобы в десятки-тысячи раз сэкономить процессорное время, диск и память это не профит?

Кто это мешает делать со структурой лога, приведенной выше? В том-то и дело, что в текущей структуре datetime и source уже есть и по ним не такая уж проблема искать. Но самое важное в логе - message. На его обработку и тратятся основные усилия. Потому я и спросил, какой более профитообразующий формат для message ты можешь предложить кроме архаичного кода ошибки, применяемого в виндовых логах?

Ты специально выбрал единственно возможный пример где от БД нет никакой пользы?

Ты предлагаешь использовать БД для похожей структуры.

like всегда был тормозом и будет им по определению.

Кроме того, что он тормоз, его возможности бедней возможностей самого только grep-а, даже без связки со всякими awk, sed и т.д. Попробуй на голом SQL отфильтровать, трансформировать, и просуммировать данные, записанные в виде строки. А любой админ постоянно с логами что-то такое делает.

Добавив более формальные условия которые известны в 99% случаев экономия конечно будет.

time cat tmp/ua.csv|grep ';0;'|grep ';10.02.2012' |tr '[:lower:]' '[:upper:]' |grep USERS | awk '{print $ 1 $ 2}'
2274255;0;10.02.201208:35;UPDATE
2274259;0;10.02.201208:41;UPDATE

real	0m0.079s
user	0m0.072s
sys	0m0.040s

SQL-вариант:

where iduser=0 and (stamp between '01.02.2012' and '11.02.2012') and statement like upper('%USERS%')
------ Performance info ------
Prepare time = 319ms
Execute time = 2ms
Avg fetch time = 0,25 ms

2274259;0;10.02.201208:41;UPDATE T_USERS SET NAME='SOMEUSER', IDWORKER=147, SMBQUOTA=500, SMBSTATUS='1', IDGROUP=21, TYP='0' WHERE ID = 111
2274259;0;10.02.201208:41;UPDATE T_USERS SET NAME='ANOTERUSER', IDWORKER=148, SMBQUOTA=500, SMBSTATUS='1', IDGROUP=21, TYP='0' WHERE ID = 222

time cat tmp/ua.csv|grep ';0;'|grep ';10.02.2012' |tr '[:lower:]' '[:upper:]' |grep USERS | cut -d';' -f4|cut -d',' -f3| sed 's/SMBQUOTA=//'| (tr "\012" "+"; echo 0)|bc
1000

real	0m0.080s
user	0m0.072s
sys	0m0.052s

он еще и в SQLite свои мерзкие ручонки суёт?!!

ждем новости:

;)

аа, фуф :)

Потому что бесполезно :) Саппорт в лучшем случае посочувствует и предложит сменить компутер.

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

Ссылку на источник «гласящего принципа» можно? А то принцип какой-то надуманный. Оптимзируют целевой параметр или группу параметров (причем. чем их больше тем хуже - тем компромисснее будет решение, если параметры зависимые: всегда размен скорости на маневренность зажор памяти, мощности на экономичность и т.д. с согласия заинтересованных лиц, если проект общий. Нельзя отдельно «пилить свой», если придется оглядываться на интересы других - если не оглядываться, тогда конешшно :) Но и все их оптимизировать тогда не надо - как впрочем, и на общий одобрямс результата рассчитывать :))

Это для системы со многими переменными :-) Если переменная одна- время загрузки то все сказанное в утиль. Спич о том что процессы загрузки и собственно работы компа разнесены по времени о общих переменных в них нуль

Но для общего времени работы пользователя за компом требуется как раз и оптимизация времени загрузки и оптимизация тех же кед итп итд. НО, это разные и разнесенные во времени процессы и оптимизация одного их них не влияет на оптимизацию другого НО, опять же, суммарная оптимизация будет больше чем оптимизация только одного из этих процессов

попонятнее
вот простейшая целевая функция оптимизации
z=ax(e1,e,e3)+by(Ё1,Ё2,Ё3:-)+cx(e1,e,e3)y(Ё1,Ё2,Ё3:-)
x - время загрузки
y - все остальное (кеда итп итд)
вот именно последнего слагаемого в общей оптимизации копма и нету, поэтому все сказанное фтопку :-)

у приложения нет своего регулятора?

А как ты сделаешь уже стандартное во всех десктопных ОС приглушение всех лишних звуков при входящем по VoIP звонке?

udev(я же полагаю карта usb-шная?)+asoundrc

Это далеко не на лету.

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

Что именно ты понимаешь под голым текстом? UTF8 без какой-либо структуры? ASCII? JSON? CSV? XML? Всё вышеперечисленное?

Что именно ты понимаешь под голым текстом? UTF8 без какой-либо структуры? ASCII? JSON? CSV? XML?

Мне нечего добавить к определению простого текста, из книжки «Программист-прагматик»

Что такое простой текст?

Простой текст состоит из печатных символов и представлен в некой форме, которая непосредственно может быть воспринята и понята людьми. Например, данный фрагмент не несет в себе смысла, хотя и состоит из печатных символов.

Field19=467abe

Читатель и понятия не имеет, каков смысл значения 467аЬе. Лучше сделать его понятным:

DrawingType=UMLActivityDrawing

Простой текст вовсе не означает, что в нем отсутствует структура; яркими примерами простого текста с четко определенной структурой являются форматы XML, SGML и HTML. С простым текстом можно проделывать все те же операции, что и с двоичным форматом, включая управление версиями.

Простой текст имеет тенденцию находиться на более высоком уровне, чем простая двоичная кодировка, обычно возникающая непосредственно из реализации. Предположим, вам нужно хранить свойство под названием usesjnenus, которое может принимать значение TRUE или FALSE. Используя простой текст, вы можете записать это следующим образом:

myprop.uses_menus=FALSE

А теперь сравните это с 0010010101110101.

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

Это далеко не на лету.

кто сказал? Прописываем туды враппером ladspa (через equal) плагин для микширования потоков, при появлении девайса рулим уровнями amixer-ом.