Оценив влияние различных факторов на время выполнения операций записи и чтения в СУБД Redis, исследователи обнаружили (http://blog.nullspace.io/kernel-latency.html), что основным источником задержек при вводе/выводе является ядро операционной системы. В частности, при выполнении в Linux операций записи 1 Кб данных в однопоточном экземпляре Redis, 84% времени выполнения запроса тратится на выполнение кода внутри ядра Linux, 13% в компонентах взаимодействия с оборудованием и только 3% непосредственно на стороне приложения. При выполнении операций чтения в ядре тратится 62% времени, а в приложении - 20%. При этом, 70% затраченного на выполнения кода ядра времени приходится на компоненты сетевого стека.
Таким образом, производительность Redis во многом упирается в скорость работы сетевого стека. Пытаясь сократить возникающие на уровне ядра задержки, экспериментаторы попытались использовать вместо Linux проект Arrakis (http://www.opennet.me/opennews/art.shtml?num=39829), в рамках которой развивается концепция ОС, минимально влияющей на выполнение приложения. Использование Arrakis позволило сократить задержки операций записи на 81%, а чтение на 65%.URL: http://blog.nullspace.io/kernel-latency.html
Новость: http://www.opennet.me/opennews/art.shtml?num=41658
Ничего, скоро Лёня ядром займётся, или своё запилит. Тогда ребята поймут, что 84% потраченного времени — далеко не предел. =)
Какой-то маразм. ОС на себя берёт всю тему общения с железом, буферезацию, размещение в (виртуальной!) памяти, следит за страницами, а БД делает write(fd, buf, sizeof(buf)) и ВНЕЗАПНО большинство времени тратится в ОС.ЭТО ПРОСТО НЕВЕРОЯТНО! Я считаю надо писать докторскую. Или как минимум кандидатскую, ВАК будет довольна.
> Какой-то маразм. ОС на себя берёт всю тему общения с железом, буферезацию, размещение в (виртуальной!) памяти, следит за страницами, а БД делает write(fd, buf, sizeof(buf)) и ВНЕЗАПНО большинство времени тратится в ОС.Таких вещей у "исследователей" не существует. Современный программистик - это функция которая за зарплату дергает методы объектов, пишет на C#, Python, JavaScript и юзерспейсом считает браузер.
> юзерспейсом считает браузер.Тот аналитик не сильно далеко ушел:
I’m still more or less a complete OS noob, in any event.
Он не аналитик, он данные берет из статьи: https://www.usenix.org/system/files/conference/osdi14/osdi14..., где умные дяди пиарят свою исследовательскую ОС.
Ты имел ввиду Java, С#, JavaScript?
>Ты имел ввиду Java, С#, JavaScript?семейство Python,C#,Java,JavaScript,VB,VBScript,...
Java, C#, JavaScript, PHP, Swift?
Не, ява он знает, а все перечисленные нет.
И тем не менее запросто может оказаться, что для данного конкретного случая ядро работает неоптимально. Причем виновата может быть любая сторона - как юзерспейс, неудачно работающий с интерфейсами ядра, так и само ядро. А может, там вообще пересборкой с другим конфигом можно обойтись. Как ни крути - локализация проблемного участка - это половина пути к решению проблемы.
> запросто может оказаться, что для данного конкретного случая ядро работает неоптимальноЯдро работает не оптимально для любого (!) конкретного случая. Ибо оптимизировать под один случай означает запороться во всех остальных.
Пример. Каждый человек может сказать что-то типа "я не властелин вселенной, а все остальные не мои рабы, значит для моего конкретного случая общественный строй неоптимальный". И ведь будет прав, ибо общественный строй, условно говоря, оптимизирован для всего общества. Вот и ядро оптимизировано только для типового набора процессов и железа (для общего случая), но не для какого-то одного процесса.
Оптимальнее всего - захардкодить частный случай в ASIC. Вот только проблема: оно совершенно не переконфигурируемо получается...
use FPGA, Luke!
Дорого.
> Дорого.
Parallella - это не FPGA.
Ну вообще-то там кроме Epiphany стоит и Xylinx Zynq 7010/7020 в которой есть 2 ядра ARM и таки FPGA на 25k/80k. И с ней вполне можно поиграться.
> Ну вообще-то там кроме Epiphany стоит и Xylinx Zynq 7010/7020 в которой
> есть 2 ядра ARM и таки FPGA на 25k/80k. И с
> ней вполне можно поиграться.Для поиграться с FPGA - параллеллы дороговаты, да и в нагрузку дают 16-ядерный меш.
Можно выбрать и дешевле $100 с 200к вентилей
> use FPGA, Luke!кстати, да
давно хотел поизучать, посоветуете что-нибудь?
начните с началаhttp://www.mike-stirling.com/retro-fpga/zx-spectrum-on-an-fpga/
>> use FPGA, Luke!
> кстати, да
> давно хотел поизучать, посоветуете что-нибудь?http://www.xilinx.com/products/boards-and-kits/device-family...
http://www.buyaltera.com/scripts/partsearch.dll/multisearch?...
Предлагаю разработать HW+OS специально для этой БД. Потому что второй пункт узких мест это HW. И не пиарить мозг
Было бы здорово
Засуньте свою софистику... подальше. В ядре шесть вагонов оптимизаций для тех или иных юз-кейсов. От различных планировщиков до поддержи разных извращений конкретного железа. Вполне вероятно, что товарищи наскочили на какой-то частный случай, для которого можно добавить поддержку.
> В ядре шесть вагонов оптимизаций для тех или
> иных юз-кейсов.В ядре, которое использовали ребята из этой новости, или в каком-то абстрактном сферическом ядре в вакууме? То-то же. Да, из исходников ядро можно собрать по-разному. Даже свои оптимизации можно добавить. И вообще, можно запилить своё ядро. Но это будет не то ядро, о котором говорится в новости. Софистика? Да ради бога.
Голосую за специализацию ОС, а не за комбайны...
А так и есть. Откройте для себя make menuconfig.
Я как-то открывал, и выяснилось что там более-менее всё оптимально и так ))
Это если мыслить не в пределах 1го хоста, использую 1 ось на всех домашних устройствах, поэтому даже выпиливание "ненужных" сегодня драйверов может завтра обернуться гемором.
Это еще Стивенс в своих книгах про UNIX API говорил, что писать маленькими блоками неэффективно. Поэтому автор Америки ни для кого не открыл.
Ну да, пофиг, что в Arrakis практически всё выполняется в пространстве приложения. Главное, что на уровне ядра у них на 81% меньше! Достижение!
> Главное, что на уровне ядра у них на 81% меньше! Достижение!Ну так вроде бы и не соврали. Просто сказали не всю правду.
А знаете, в DOS можно вообще отделаться от овертеться от оверхеда на переключение контекстов и не надо ни с кем делить процессорное время. Правда радости с этого что-то мало...
>> Главное, что на уровне ядра у них на 81% меньше! Достижение!
> Ну так вроде бы и не соврали. Просто сказали не всю правду.
> А знаете, в DOS можно вообще отделаться от овертеться от оверхеда на
> переключение контекстов и не надо ни с кем делить процессорное время.
> Правда радости с этого что-то мало...Не мало. DOS (а именно FreeDOS) - это лучшая реалтаймовая система из доступных сейчас. С прекрасной обратной совместимостью, прошу заметить. Для определённых задач (не требующх многозадачности и разделения прав доступа) - самое оно.
> Не мало. DOS (а именно FreeDOS) - это лучшая реалтаймовая система из
> доступных сейчас.Булшит. Эталонный. От овоща застрявшего в 80-х прошлого века.
1) У х86 как такового с реалтаймностью - хреново! Мягко говоря. Ну то что jitter за счет cache hit/cache miss адский - думаю все давно поняли. Но это было бы слишком просто. Поэтому интел сделал SMM. Встанет у тебя какой-нибудь обработчик SMM на секунду в немеряном блобе биоса - и пусть весь мир подождет! Запретить вход в SMM нельзя - это самый привилегированный режим проца, ОС как максимум может лишь пост-фактум заметить что куда-то пропало процессорное время - видимо, кантовались в SMM. Ты как, готов расписаться за всю жизнедеятельность проприетарного биоса своей головой? А гарантии времен отклика возьмешь с традиционного места - с потолка?
2) Ссаный двухбаксовый микроконтроллер по части реалтаймности натянет все это безобразие с огромным отрывом и будет на порядки предсказуемее.
3) Дос "лучший" только для ретардов которые слаще морковки ничего не ели. Более дepьмово сделанной системы - еще поискать. Услуг минимум и они кривые, куча легаси и прочая. Модель памяти? Над ней угорает даже двухбаксовый микроконтроллерный ARM, где и то нынч есть нормальное плоское фоннеймановское 32-битное адресное пространство, без сношания мозга програмеру сегментацией и совершенно левыми ограничениями на ровном месте.> С прекрасной обратной совместимостью, прошу заметить. Для определённых
> задач (не требующх многозадачности и разделения прав доступа) - самое оно.При условии что вы безнадежный некрофаг, застрявший в развитии в своих 80-х.
Хе-хе, переход оппонента на личности - дучшее доказательство моей правоты :)
> Хе-хе, переход оппонента на личности - дучшее доказательство моей правоты :)Это не так. И своим сообщением вы подтвердили свою глупость.
> Хе-хе, переход оппонента на личности - дучшее доказательство моей правоты :)К сожалению, совсем без перехода на личности очень сложно высказаться об оппоненте, который считает DOS лучшей реалтаймной системой... в 2015 году!
Прочитайте внимательно сначала то, что я написал. Не лучшей _вообще_, а лучшей из _доступных_ и _только_ под определённые задачи. И больше не выдавайте свои фантазии за чужие слова.Да, и Линукс я тоже использую. Очень интенсивно.
>[оверквотинг удален]
> с огромным отрывом и будет на порядки предсказуемее.
> 3) Дос "лучший" только для ретардов которые слаще морковки ничего не ели.
> Более дepьмово сделанной системы - еще поискать. Услуг минимум и они
> кривые, куча легаси и прочая. Модель памяти? Над ней угорает даже
> двухбаксовый микроконтроллерный ARM, где и то нынч есть нормальное плоское фоннеймановское
> 32-битное адресное пространство, без сношания мозга програмеру сегментацией и совершенно
> левыми ограничениями на ровном месте.
>> С прекрасной обратной совместимостью, прошу заметить. Для определённых
>> задач (не требующх многозадачности и разделения прав доступа) - самое оно.
> При условии что вы безнадежный некрофаг, застрявший в развитии в своих 80-х.Истерикой удовлетворен однозначно
> Истерикой удовлетворен однозначноУдачных вам продаж! :)
> Истерикой удовлетворен однозначно[Шепотом]: А сколько дадите за адрес стройки, за которой никто не следит, и где есть 6 этажей кирпичей? ;-)
//Шучу если что, органам правопорядка расслабиться.
>исследователи обнаружилииследователи == британские учёные ?
>>исследователи обнаружили
> иследователи == британские учёные ?Знакомьтесь:
""Computer "scientist" // Alex Clemmer is a computer programmer. Other programmers love Alex, excitedly describing him as "employed here" and "the boss's son". -- http://blog.nullspace.io/
""Alex Clemmer obtained a BS in computer science from a middle-of-the-road state school in 2013. He had an ok-but-not-great GPA. 3 out of 5 officemates agree that Alex has programmed before.
""Alex is currently employed at Microsoft. --http://www.nullspace.io/
Это всё объясняет...
> Это всё объясняет...А я то думаю - где же я этот стиль видел, когда вроде бы и не соврали, но сказали не всю правду. А оно "свое, родное" - в смысле, методам научилось прямо там где они и возникли.
Сначала расстроился, неужели всё так плохо ?
Но потом вспомнил что в TOP500 более 90%
занимает Linux. По моему там объёмы информации
немалые.Улыбнуло. Недоперезап*сделись...
А моська продолжала тявкать...
А в Microsoft вообще-то молодцы, в плане
подрывной деятельности экосистемы Linux преуспели.
> подрывной деятельности экосистемы Linux преуспели.Интересные у них подрывы - отгружают свои даунлоады линуксным AKAMAI'ем.
http://nmap.org/book/vscan-examples.html
90% от этого куска - тупая запускалка приложения. Ребутнулись - потянули по pxe все - запустили - слили.
Этим стоит гордиться ?
Аракис еще более тупая запускалка приложений, в котором вынесли все что можно в userspace
> Alex is currently employed at Microsoft. --http://www.nullspace.io/А еще смотрим в http://www.opennet.me/opennews/art.shtml?num=39829
> Arrakis, являющейся форком исследовательской ОС Barrelfish,http://www.barrelfish.org/
> operating system being built from scratch and released by ETH Zurich in Switzerland, with assistance from Microsoft Research.Какое неожиданное совпадение! )
Зря ты так ...
Microsoft Research - уважаемая контора.
> Microsoft Research - уважаемая контора.Кем?
Это что, история из цикла "я отправил посылку, 80% времени она провела в пути и только 20% в других местах"?
:)a la poste Russe ?
redis-kerneld
a если вместо Arrakis взять ms dos, то 100% будет в режиме приложения :)))
А ведь это и правда очень много. KERNEL значительно выше суммарного времени HW + APP. 80% всего времени уходит на нужды ядра и устройства. Просто фантастика!
> устройства. Просто фантастика!Да вообще офигеть - всегда можно найти какой-то краевой случай к которому можно докопаться.
Разница в 5 раз! Это недопустимо! Нужны более эффективные алгоритмы. Возможно - механизмы. Самое время "грызть" Кнута с Таненбаумом вместе.
Я конечно не семь пядей во лбу, но в моем понимании суммарное время работы KERNEL в идеале не должно превышать HW. Или как минимум меньше HW+APP чтобы не стать тем самым узким местом.
Ok. тогда kernel не будет работать с памятью, контекстом, буфферизациями и прочей ненужной фигней.
> Ok. тогда kernel не будет работать с памятью, контекстом, буфферизациями и прочей
> ненужной фигней.Если водитель с машиной на доставку товара тратит времени в 5 раз меньше, чем на обслуживание это же машины в гараже, то что-то не так в консерватории.
Если ускорение от буферизации дает +5% (абстрактно) к производительности, а на обслуживание буферизации тратится -20%, то такая буферизация вредна.
Так что время kernel в пять раз превышающее время app+hw навевает на мысль, что kernel сильно не оптимален.
> Если водитель с машинойUmmm, автомобильные аналогии!
>навевает на мысль, что [CENSORED] сильно не оптимален.
> Так что время kernel в пять раз превышающее время app+hw навевает на
> мысль, что kernel сильно не оптимален.Только на этой задаче, при непонятных условиях.
Кстати, автор в комментах пишет:"It is frustrating to hear that you didn't bother reading the article closely enough to realize that I didn't run any experiments. This is a recap of an interesting experiment I found in a research paper."
Т.е. "Я сам ничего не мерял, это перепечатка эксперимента, прочитанного где-то на заборе". Вполне в духе аддиктов Микрософт. "Не читал, но осуждаю" ))
За такое вполне можно было бы подать иск, ибо Клевета в чистом виде - обгаживание репутации продукта.
Поэтому приложения пилят в виде ядра, пример Mirage OS на языке ocaml
- http://www.openmirage.org/В общем любое решение BareMetal OS, проще сложного управления в ядре...
> В общем любое решение BareMetal OS, проще сложного управления в ядре...Спору нет, погадить можно и в чистом поле, а вместо строительства теплой комфортной хаты - быстренько накидать себе шалаш из веток и травы. Но почему-то такое решение устраивает далеко не всех. Хоть это и менее трудозатратно.
блин, если им в СУБД Redis что-то не нравится в ядре Linux никто не запрещает пересобрать его для себя со своими патчами и заткнуться...
> заткнуться...Учитывая что чувачок из микрософта - я думаю что линукс он видел на картинке. Ну может быть виртуалочку на хипер-в запустил.
> Ну может быть виртуалочку на хипер-в запустил.С лету прочиталось как "хипстер-в"
Фрейд одобряет ))
А что, лучше было бы, если ядро слепо брало кусок данных из одного места и пихало в другое, без каких-либо проверок?
И что за крики? Ну обнаружили узкое место - вот и отлично. Теперь либо товарищам укажут, где именно они косячат, неудачно взаимодействуя с ядром, либо будет хороший кейс, на котором можно покопать и подправить реальные узкие места в ядре. Собственно, так обычно развитие и идёт.
Если бы они хотели исправить, хотя бы вывод perf привели. Ну и сетевые настройки, с которыми получились такие плохие значения (как минимум опции драйвера и ethtool -c, ethtool -k). А то статья написана в духе "в линуксе все так плохо, а вот Arrakis рулит, за ним для наших задач будущее", конкретики - как повторить тест и даже какой-либо подробной информации о том, *где именно* плохо они не привели.
Ну если не приведут - их забудут за неделю. А вот если приведут - есть шанс поиметь с этого полезные результаты в виде оптимизации кода - хоть ядра, хоть редиса.
Все должно аккуратно укладываться в рамки здравого смысла. Результат 5 к 1 - туда явно не вписывается. Значит бред и что то нужно менять. Сомневаюсь, что проблема ограничивается одним лишь Redis. Рекомендую прочитать оригинал и сопутствующие документы.
В комментариях вся суть местных дегенератов. Вместо того, чтоб отнестись к новости разумно, критически, сходить, проверить данные тестов, осмыслить, местная петушня восприняла новость как личное оскорбление, порочащее неприкасаемую святыню, поспешив наклеить всевозможные негативные ярлыки на авторов исследования
И правда, удивительно: чего это местные посетители критически воспринимают статейки от микрософтовского кекса, у которого самое подходящее описание - "мой папа - босс".Ну а бонусом - ваш комент вообще образец культуры и терпимости, чего уж. НеПетyшня, блин, проприерасовская. Ус у вас отклеился.
Конечно можно создать ОС с кучей всяких "нужных" проверок которые так или иначе повысят ее безопасность, но сделают ее крайне медленной. Кому она после этого будет нужна? Важен баланс, а если его не удается достичь - другой механизм который обладает нужными эксплуатационными характеристиками. Не все такие как Кнут или Таненбаум, поэтому ядром должны заниматься "избранные" и обязательно математики. Любая предполагаемая реализация должна пройти математический анализ. Время, когда каждый может что то написать "на коленке" - прошло. Только специалист высшего класса осилит все это. Дорогой специалист. Каждый должен заниматься своим делом. Не в обиду другим.
> поэтому ядром должны заниматься "избранные" и обязательно математикиОтличный рецепт эпик фейла.
Помнится, в середине 90-х игроделы не писали игр под винду, потому что у нее были больщие накладные расходы по сравнени с DOS. Товарищам из редис тоже могут перейти на FreeDOS какой-нибудь :)
кстати в DOS можно накладные ресурсы ОС вывести в 0. притом вполне штатно.
> кстати в DOS можно накладные ресурсы ОС вывести в 0. притом вполне штатно.Можно. Но почему-то желающих пользоваться DOS нынче мало. Еще можно программу на чистом асме написать. Если программа мелкая - будет круто. А если не очень - будет жутко.
ох ребятки, для начало нужно знать что за сетевые карточки они юзали.
> ох ребятки, для начало нужно знать что за сетевые карточки они юзали.Не очень принципиально, когда 84% в коде в EXT4 :)
Цитата из новости: "При этом, 70% затраченного на выполнения кода ядра времени приходится на компоненты сетевого стека".
> Цитата из новости: "При этом, 70% затраченного на выполнения кода ядра времени
> приходится на компоненты сетевого стека".Ну так EXT4 и расшифравывается как Enterprise eXtandable TCP v 4
> Цитата из новости:Ять, вот обезьяны, 84% взяты с диаграммы на сайте. Я конечно понимаю что ссылки никто не клацает..
Intel x520 10G NIC
Провел свое собственное исследование. Взял за основу рабочий код!
#include <stdio.h>
int main(void)
{
for (int i = 0; i < 3000000;i++) {
putchar('0');
fflush(stdout);
}
return 0;
}
Обнаружил, что 87% времени выполнения тратится на выполнение кода внутри ядра!gcc49 -O2 -std=c99 -Wall test.c
$ time ./a.out > /dev/nullreal 0m1.173s
user 0m0.142s
sys 0m1.030s
Долго думал, решил убрать fflush и проверить еще раз -- НЕВЕРОЯТНО, но это позволило сократить задержку записи в ядре в 114 раз!!$ time ./a.out > /dev/null
real 0m0.019s
user 0m0.010s
sys 0m0.009s
хороший пример. Анонимус одобряет
> это позволило сократить задержку записи в ядре в 114 раз!!Теперь я понимаю как ты получаешь квартальную премию :)
Какое отношение ваш пример имеет к сетевому стеку Linux? В оригинале статьи было четко указано, что 70% времени всего времени было потрачено на сетевую подсистему. Вы явно не читали.
Не мешай исследованию! Человек почти диссертацию написал же. </>
> Какое отношение ваш пример имеет к сетевому стеку Linux?Мне было влом делать пример с сетью? =)
Принцип ведь тот же -- толком неизвестно, где и почему задержка. Возможно не очень оптимальный код редиса, возможно ядра или конкретно конфигов для тестированного железа. Возможно эта "неоптимальность" необходима в продакшене (как например sync-и/всякие barrier-ы в ФС, хотя без них в бенчах все работает в несколько раз быстрее) а тесты с арракисом -- работают отлично только на сферических железяках.
> Вы явно не читали.
Было бы что читать -- "мы протестировали редис и оказалось что ядро дает задержку в х%!"
А что, как, с какими конфигами, как повторить -- это ведь на самом деле не важно, да :)
Почему то напомнило эту новость http://www.opennet.me/opennews/art.shtml?num=31211
> Почему то напомнило эту новость http://www.opennet.me/opennews/art.shtml?num=31211Да они контрибутят только крап для своего же hyper-v. Не хотят, понимаешь, в их облаке маздайкой пользоваться. Цены на лицензии и потребление ресурсов виндой делает сервера на них в разы дороже линуксных.
Я не поэтому вспомнил, а потому что как показано в новости одно и тоже (коммиты) можно посчитать по разному и получить совершенно разные результаты.
используйте MariaDB
Используйте Mozilla Firefox.
> Используйте Mozilla Firefox.Эйрбасы прикольнее. Но правда дороже.
> Используйте Mozilla Firefox.fix: Icecat
Ждем измерений на freebsd
> Ждем измерений на freebsdОга, на ZFS. Чтобы батхерт был пожестче.
Редис хранит все в памяти, так что zfs тут вообще не к месту.
> Редис хранит все в памяти, так что zfs тут вообще не к
> месту.И тут-то можно привести тест Вычитки в память всей базы, при запуске. И сравнить.
А ничего что redis при всем своем крутом api однопоточный?
> А ничего что redis при всем своем крутом api однопоточный?API там не крутой, а простой как 2 копейки. Однопоточность не смущает.
Простой API это memcached.
Однопоточность не смущает только тех кому плевать на скорость.
> Простой API это memcached.
> Однопоточность не смущает только тех кому плевать на скорость.lighttpd и ngnix рыдают в углу.
>lighttpd и ngnix рыдают в углу.дядя ты хочешь сказать что nginx однопоточный? Ты каких грубов поел?
кретинов я к обсуждению не приглашал. брысь.
Плохому танцору сапоги мешают
Чтой-то я по ссылке не увидел, а какая же итоговая пропускная способность этой Redis под Linux и Arrakis.А вот это меня особенно повеселило "проект Arrakis, в рамках которой развивается концепция ОС, минимально влияющей на выполнение приложения".
> При этом, 70% затраченного на выполнения кода ядра времени приходится на компоненты сетевого стека.Смешно читать такое от сотрудника Макрасофта, при том, что в винде сетевой стек работает гораздо медленнее.
Типичная американская выходка и мышление: "У нас всё плохо с сетью.. Что же делать? А давай скажем, что У НИХ всё плохо с сетью, и на нас меньше думать будут? А давай! В общем мы тут исследовали вашу Линукс и поняли что ... ... "
Если бы всё было так просто... Мелкософт уже не конкурент, и большинству это очевидно. Тут, скорее всего, лишняя рекламация проекта Arrakis. Это ведь концепция ядра, написанная под лицензией MIT.Вы заметили, как модно стало переписывать то, что уже реализовано в рамках GNU-лицензий, под не копилефт лецензиями? LLVM был только началом. Вот теперь сюда Arrakis можно присовокупить.
Если в программе очень мало собственной логики, а вся работа выполняется на уровне OS - вполне нормальные цифры.
А еще и взаимодействие с OS организовано не оптимальным образом...
> А еще и взаимодействие с OS организовано не оптимальным образом...Тише-тише!! А то ж кто-нибудь услышит!? И не дай б. подумает, что высокопроизводительный бенчмарк высокопроизводительного сервера в высокоинтеллектуальном бложике высокообразованного сыночка босса в майкрософтах -- не использовал асинхронные сетевые api. </>
не зря ORACLE ASM предлагает
> не зря ORACLE ASM предлагаетнедаром и неспроста, да.
К чёрту ненужные слои абстракции! DB2 for Z-OS - в массы!
> К чёрту ненужные слои абстракции! DB2 for Z-OS - в массы!Сколько ассемблеров выучил ты [в свои годы] ?!
---машинные коды? тумблер-панели? мы же не изверги!?
хе ... тумблер панели :-)А ещё была консольная пишмашинка :-D
> хе ... тумблер панели :-)
> А ещё была консольная пишмашинка :-DКонсул. Ты ее издали видел или реально использовал?
> позволило сократить задержки операций записи на 81%Только нечаянно забыли написать общее время.
> Только нечаянно забыли написать общее время.Дело было не в бобине )))
> упирается в скорость работы сетевого стека...без хвостовой рекурсии сложновато идет оптимизация...
Да, похоже ядро надо исключить из этих операций. )))
Срочно!
Это ускорит работу )))
Вобще смех-смехом, однако иногда и правда стоит делать некоторые оптимизации, к примеру на каждый чих не считыват конфиг сети с диска, а хотя-бы с на минуту его закешировать где-нить в памяти.
Я встречал на форточках, при мониторинге активности - винда постоянно тыкается в реестр, что-бы прочитать данные по текущей теме оформления или каких=нибудь настройках.
Есть такая проблема, хотя в (0) она изложена пренебрежительно и неаккуратно.
В случае Windows - это нормально. Весь реестр всегда хранится в оперативной памяти. Не вижу смысла тут что либо оптимизировать.
> В случае Windows - это нормально. Весь реестр всегда хранится в оперативной
> памяти. Не вижу смысла тут что либо оптимизировать.А в случае линукса файловый кэш во все поля.
Только представьте что память начала кончатся, и файловый кэш дропнули, а вам реестр в винде в файл подкачки уехал.
Вы плохо знакомы с архитектурой Windows. Не стоит допускать острой нехватки памяти. В этом случае, навряд ли можно в чем то винить OS.
> Вы плохо знакомы с архитектурой Windows. Не стоит допускать острой нехватки памяти.
> В этом случае, навряд ли можно в чем то винить OS.Зато хорошо знакомы с Microsoft SQL Server, у которого память "утекает" со временем, и надо делать рестарт службы руками. В это время все кассовые терминалы, и прочие юзеры курят и ждут, ждут, ждут....
В линуксе даже на случай "Замуровали, демоны!" есть Alt+Shift+SysRq.
Без размещения базы данных на внешнем usb-накопителе эксперимент неполон.
И чего же тут удивительного? Если операция не особо сложнее доступа к массиву и занимает менее сотни тактов процессора, то даже копирование результата может занять времени больше чем поиск значения.
Конечно можно не сомневаться, что сетевой стек избыточен, ОС должна упаковать данные в пакет, посчитать чексуммы, прогнать через несколько слоёв фильтрации, пройтись по таблице маршрутизации, сообщить сетевой карте о необходимости передать пакет. Redis мог бы урезать пару из этих операций, будь он подключен непосредственно к драйверу сетевой карты.
Плохому программисту ядра мешают
Ага, щас запилят свою ось, потом фс к ней приделают, потом драйвера, потом еще дыры латать пяток лет будут, а потом окажется, что получись тоже самое только кривое и не совместимое.
> Ага, щас запилят свою ось, потом фс к ней приделают, потом драйвера,
> потом еще дыры латать пяток лет будут, а потом окажется, что
> получись тоже самое только кривое и не совместимое.Зато теплое, ламповое, своё!
И клиентура уже сложилась. Вовлечь юзера в тестирование своей продукции, чтобы он чувствовал, что в хорошей ОС есть и капелька его победы - лучше, чем сразу выкатить годный продукт. Всё равно ведь придерутся.
Шах, и мат, любители монолитных ядер... ;-)
Кстати наводит на мысли о закате эры многозадачности. Главная функция современной ОС - планировщик многозадачности, все остальные функции (графическое окружение, файловая система) в существенной степени самостоятельные сервисы, хотя рядовой пользователь этого и не осознаёт. В наше время наблюдается тенденция о замене многозадачных железных серверов виртуальными машинами, на которые воскладывается ровно одна задача (гонять тот же Редис, например) (пользователи Docker уже приучаются даже SSH вторым сервисом не использлвать) а единственной функцией железа становится быть хостами для виртуальных машин. В результате очень много кода становится лишним. По идее можно ожидать появления ОС без ФС (зачем она, если для множества задач, включая СУБД и статику удобнее напрямую адресовать рабочую область диска и не нужно распределять права доступа на уровне ФС), без пользовательской оболочки и с сильно упрощённым планировщиком (без процессов - только потоки).
я очень тебя разочарую, если скажу, что такие ОС давным-давно есть? да-да, те самые «бесполезные микроядерные игрушки».