Re[8]: диалог с любителями потоков
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.07.09 16:04
Оценка: -11
Здравствуйте, Gomes, Вы писали:

G>Вот скажи, что заставляет высказывать подобное, абсолютно не разбираясь в теме? Лично я, если чуть в сторону от своей специализации — буду задавать вопросы и конспектировать. Так что, если что не понятно — спрашивай


Не тебе судить о том в чем я разбираюсь. Ты никто и зовут тебя никак. Так что спрашивать тебя мне не о чем. Одью.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: диалог с любителями потоков
От: mrTwister Россия  
Дата: 15.07.09 08:14
Оценка: +3 -1
Здравствуйте, VladD2, Вы писали:

T>>Опыт профилирования.

VD>Твой? Это уже является показателем?
Разумеется. "Практика — критерий истины" (с)

T>>Именно поэтому многие высоконагруженные веб-приложения написаны на тормозных скриптовых языках.

VD>Я таких не знаю. Ну за исключением тех что написаны на Эрланг. Только это как раз совершенно другой случай.
Ну вот, например, эти были написаны на PHP: Facebook, Wikipedia (MediaWiki), Yahoo!, WordPress, YouTube, MyYearbook, Digg, Joomla, Tagged.

T>>Да. Тут имеют место массовые обращения через порты ввода-вывода к БД, распределенному кешу, файловой системе и т.д.

VD>А СУБД, по-твоему, только к дискам обращается? Данные она не обрабатывает? План построения запросов, соеденения, фильтрацию, кэширование не она делает? На это время не тратится?

Клиенту СУБД (то есть Web-серверу в нашем случае) совершенно плевать, что там делается внутри СУБД. Клиент общается с базой через порты ввода-вывода (сеть, трубы). В этом смысле, для него любое обращение к базе — это стандартная IO операция, которая отлично ложится на IOCP.

VD>>>Мне кажется, что IO — это тоже вычисления в массе своей.

T>>Это неважно,

VD>Это очень важно! Только это и важно. Если бы все упиралось в медленные устройства ввода-вывода вроде дисков, то твоя позиция имела бы смысл. А так, 99% времени, при обработке веб-запроса, тратится на вычисления. Если бы они работали параллельно и с минимальными затратами, то пользователи были бы удовлетворены. А так пользователь ждет, железо занимается непроизводительными вычислениями, а горе программисты оправдывают эту ситуацию разными глупостями.

Вычислениями занимается не Web-сервер (о котором идет речь в этой ветке) а СУБД.

T>> Базе данных плевать на то, какого цвета потоки у веб-сервера: зеленые или ещё какие. Ей пришел запрос на IO порт, БД запрос обработала, и выплюнула обратно ответ. Веб сервер всё это время ждал, а не занимался никакими вычислениями.

VD>Процессоров в сервере ограниченное количество. Если веб-сервер ждет ответ от СУБД, то процессор занимает СУБД. Это ни разу не ускоряет ни ответ текущему пользователю, ни параллельным.

VD>Если бы веб-сервер и СУБД работали в легких процессах, то при передаче запросов от одного к другому не пришлось бы переключать контекст потока ОС (вызов можно было бы осуществить в рамках того же потока), а сам вызов стоил бы многократно дешевле.


Чтобы Web-сервер по сети обращался к СУБД, которая находится на другой машине и при этом выполнение запроса бы происходило в одном процессе и потоке с Web-сервером — это круто!!!
лэт ми спик фром май харт
Re[3]: диалог с любителями потоков
От: Gomes Россия http://irazin.ru
Дата: 02.07.09 13:37
Оценка: +1 :))
Здравствуйте, VladD2, Вы писали:

VD>IIS вроде бы выделяет, но все им пользуются тем не менее.

[отпрыгивает]
Да ладно!
Re[29]: диалог с любителями потоков
От: yuriylsh  
Дата: 18.07.09 02:33
Оценка: 1 (1) +1
Здравствуйте, BulatZiganshin, Вы писали:

BZ>Здравствуйте, Sinclair, Вы писали:


BZ>>>синхронно — нет, есть кеш на RAM

S>>Тем не менее именно из-за этого происходит деградация скорости записи. Сначала свободных страниц хватает; затем рано или поздно они кончаются, и запись каждой страницы ведёт к предварительному стиранию блока.

BZ>это не *обязательно* делать синхронно


В том-то и дело, что обязательно. Проблема в том, что диск понятия не имеет что какая-то страница была удалена. Операционка не посылает команды удаления (TRIM) диску ибо ее чего? — правильно, нету. Диск узнает что у него проблемы в тот момент, когда ему приходит команда на перезапись, и соответсвенно, решает ее (вот где тормоза) только в этот момент – тобишь, синхронно. Попробую обяснить.
В SSD диске нет доступа к отдельной ячейке (байту). Ячейки организованы в страницу (4Кб). Страницы, в свою очередь, организованы в блок из 128 страниц – 512Кб. Давай представим, что мы записали файл размером в 32 страницы (128Кб) в блок. Затем еще один файл размером 64 страницы. Дальше мы удалили первый файл – так как команды удаления для диска нету, то ОС помечает у себя что первые 32 страницы блока свободны и на этом все с удалением (диск вообще в радостном неведении об этом событии, поэтому, все что происходит дальше, ему приходиться делать синхронно). Итого у нас 32 страницы в начале блока свободны, причем об этом знает только ОС (пометим эти страницы как С) – но не чисты (Ч), 64 заняты (З) и 64 страницы в конце чисты: блок выглядит так — СЗЗЧЧ. Теперь мы хотим записать в этот блок файл размером 96 страниц (как раз для наших С + ЧЧ). Вот тут у SSD диска проблема – писать в свободные страницы он не умеет, только в чистые, тобишь, ему С + ЧЧ надо превратить в Ч+ЧЧ, тобишь, стиреть первые 32 страницы. Дальше – лучше, стирать (на самом деле – перезаписывать) отдельные страницы он тоже не умеет, только весь блок. Вот тут ему нужно выкручиваться и вот тут и начинаются обсуждаемые тормоза (причем – синхронно) Что он делает – читает весь блок в кэш, в кэше удаляет первые 32 страницы, производить запись нового 96-страничного файл и с кэша весь блок пишет обратно на диск. Т.е. СЗЗЧЧ –> копируем в кэш –> ЧЗЗЧЧ –> ЗЗЗЗЗ –> копируем обратно с кэша на диск. Итого, запись 96 страниц превращается в копирование 128 страниц в кэш, манипуляции в кэше и запись 128 страниц обратно на диск. Оверхэд очевиден.
Что делает TRIM – он позволяет при удалении нашего первого 32-страничного файла (та операция, про которую я писал, что диск в радостном неведении относительно этого удаления) операционке сказать диску (посылкой команды TRIM) что странци, отведенные под файл нужно очистить (тут диск все так-же пляшет ЗЗЗЧЧ–>кэш–>ЧЗЗЧЧ–>диск). Но он это делат, когда файл удаляется, а не во время записи следующего файла, что уже дает существенное ускорение при повторной записи. Правда, с замедлением операции удаления — но тут уже можно изврящаться с асинхронностью и другими оптимизациями.
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Re[3]: диалог с любителями потоков
От: Mr.Cat  
Дата: 01.07.09 06:39
Оценка: +2
Здравствуйте, sluge, Вы писали:
S>а если с++ или жаба?

Мой поинт в том, что с философской точки зрения большое количество "потоков" — вполне нормальный подход.
Понятное дело, что для такого подхода нужно выбирать соответствующие средства реализации. Будь то green threads или грамотно используемый пул потоков.
Re[4]: диалог с любителями потоков
От: jedi Мухосранск  
Дата: 01.07.09 08:09
Оценка: +2
Здравствуйте, SkyDance, Вы писали:

S>>а если с++ или жаба?


SD>В С++, особливо на виндах, — проблема. Стек на 1000 процессов выест 1000 * 10 Мб (по дефолту) = 10 Гб виртуальной памяти, в 32 бита (2 Гб предел) уже не лезет. Проблема реально существует, мы с ней боролись. Сначала уменьшением аппетитов (до 1 Мб стека), потом стало понятно, что делу это не поможет и консолидировали потоки. Стало намного лучше работать.


МСДН говорит 1 мегабайт по умолчанию на поток:

The default size for the reserved and initially committed stack memory is specified in the executable file header. Thread or fiber creation fails if there is not enough memory to reserve or commit the number of bytes requested. The default stack reservation size used by the linker is 1 MB. To specify a different default stack reservation size for all threads and fibers, use the STACKSIZE statement in the module definition (.def) file. The operating system rounds up the specified size to the nearest multiple of the system's allocation granularity (typically 64 KB). To retrieve the allocation granularity of the current system, use the GetSystemInfo function.


Хотя это конечно не повод плодить по потоку на коннекшн А если сильно хочется — то легкие потоки.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
Re[5]: диалог с любителями потоков
От: SkyDance Земля  
Дата: 01.07.09 10:50
Оценка: :))
CC>А при чем тут вообще С++?

Потому что в жабе потоки сразу обычно легковесные — и без всяких CreateThread.

CC>Можно было попробовать еще на Fiber-ы перенести, некоторым помогало.


Старые legacy, когда там уже мегатонны древючего кода намучены, рефакторить в таком объеме было просто "ссыкотно" (С).
Re[9]: диалог с любителями потоков
От: Sinclair Россия https://github.com/evilguest/
Дата: 09.07.09 02:59
Оценка: +2
Здравствуйте, VladD2, Вы писали:
VD>Про сокеты речи и не шало. Речь шла о праллельных запросах.
Не очень понятно, что такое "запрос" в твоей интерпретации.
VD>И более 10 их окучить не удастся. При этом будет не хилый оверхэд на переключение контекста.
А кто тебе сказал, что будут вообще переключения контекста?
VD>Почитай про эрланг. Для него (хотя язык интерпретатор) и 1000 праллельно работающих задач — это нормально.
Ты намекаешь на то, что в эрланге низкая стоимость переключения контекста? Потому что получить 1000 параллельно работающих задач на 4х ядрах невозможно — всё равно 996 будут ждать исполнения. Чудес не бывает.

VD>А меня и уверять не надо. Я и так заню, что подход фиговенький.

Ну, я не стану давать тебе советов, но лично я бы сначала ознакомился с предметом. А уже потом делал выводы.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[9]: диалог с любителями потоков
От: Gomes Россия http://irazin.ru
Дата: 09.07.09 05:36
Оценка: +2
Здравствуйте, VladD2, Вы писали:

VD>Не тебе судить о том в чем я разбираюсь.

Твои посты обо всем говорят. Только никто тебе это прямо сказать не захотел.

VD>Ты никто и зовут тебя никак.

Базару нет. Зато о тебе вчера по первому каналу рассказывали.

VD>Так что спрашивать тебя мне не о чем. Одью.

Угу.
Re[12]: диалог с любителями потоков
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.07.09 19:58
Оценка: +1 -1
Здравствуйте, Sinclair, Вы писали:

S>>>Потому что получить 1000 параллельно работающих задач на 4х ядрах невозможно — всё равно 996 будут ждать исполнения. Чудес не бывает.

VD>>Для клиентов их запросы будут обработаны параллельно. И это главное.
S>Ну конечно же не будут. Чудес не бывает.

Если хоть сто раз повторить "сахар" то сладче не станет.
Та же фигня и тут. Хоть 100 раз повтори ничего не изменится.
Чудес конечно не бывает, на многозадачность на основе переключения задач никто не отменял. Для клиента важно не то за сколько выполнен его запрос, а то через сколько он начнет получать ответ. Если его запрос простоит в очереди 10 секунд, а потом будет выполнен за 0.001 секунды, то для него это будет медленно.

VD>>Потоки дороговаты для таких задачей.

S>Совершенно верно. Поэтому никто не применяет 1 поток на 1 клиента. Делают легковесные потоки. В Эрланге это просто реализовано из коробки; остальным приходится прогибаться вручную.

Я не очень понимаю о чем в данном случае идет речь. В IIS используются полноценные потоки. Комплейшон порты и очереди — это конечно хорошие оптимизации, но только для подхода где нет легких потоков (а лучше процессов).

Тут все, как бы, очень просто. Для работы программисту удобнее чтобы каждый отдельный запрос выполнялся бы в отдельном потоке или процессе. Если поток/процесс дешев, то это отличное решение, причем, не требующее дополнительных оптимизаций. Но потоки в современных ОС не дешевы. Переключение контекста дорогое удовольствие. Причем чем больше переключений (т.е. больше потоков) тем дороже.

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

Уверен, что производительность при этом увеличилась бы очень существенно.

Собсвтенно к чему я виду. Идея создавать по потоку на запрос — очень сдравая идея. Проблема только в стоимости переключения контекста. Снизить ее и все будет ОК. А пока что получается, как всегда, выбор из двух зол наименьшего. Мы все же имеем отдельные потоки на каждый запрос, но с кучей оптимизаций и прогибов (это я про очереди ожидания).

VD>>Ну, дык ознакомься. Только сразу с двумя. Тогда и поговорим. ОК?

S>Продолжаю непонимать, чего именно я не знаю об Эрланге такого, чтоб не мог рассуждать о его производительности применительно к протоколу HTTP.

Протокол тут индифферентен. Тут важна сама идея массово-парцелльных вычислений. Дешевые процессы и посылка сообщений. Как только мы имеем две этих вещи, то идея по потоку на запрос становится совершенно здравой. Ну, возможно по потоку на сессию, чтобы было где состояние хранить и не надо было бы огромный влюстэйт гонять (или в БД его пихать).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: диалог с любителями потоков
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 09.07.09 03:36
Оценка: 62 (1)
Здравствуйте, Sinclair, Вы писали:

S>На немерле можно было бы вообще замутить всё еще круче, если только знать, что именно круче. Пока что лично мне неочевидно, какой именно синтаксис тут будет нужен. Мы это кратко обсуждали с Джеффри — я предлагал автоматически заменять в линейном коде блокирующие вызовы на "точки переключения" контекста лёгкого потока. В ответ Рихтер указал на то, что уже сейчас в Power Threading есть возможность указать N запросов для параллельного исполнения, что недостижимо при "обычном" синтаксисе.


В axum есть возможность делать асинхронные вызовы, выглядяще как синхронные и запускать множество таких параллельно.
Причем средставми метапрограммирования имхо тоже самое достижимо будет и в nemerle.
Re[24]: диалог с любителями потоков
От: BulatZiganshin  
Дата: 16.07.09 09:35
Оценка: 60 (1)
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, BulatZiganshin, Вы писали:

BZ>>последовательные перезаписи идут в другие физически ячейки. а насчёт trim ты прав
S>Рано или поздно "другие" ячейки кончаются.

если нагрузку размазать равномерно по диску, то получится что-то в районе 100 гб*миллион перезаписей, т.е. на диск за его жизнь можно записать 100 миллионов гигабайт
Люди, я люблю вас! Будьте бдительны!!!
Re[23]: диалог с любителями потоков
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.07.09 08:38
Оценка: 9 (1)
Здравствуйте, Mr.Cat, Вы писали:
MC>А где можно почитать, как решили?
Конечно же, в блоге E7. Решили путём поддержки операции Trim.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[21]: диалог с любителями потоков
От: BulatZiganshin  
Дата: 15.07.09 15:05
Оценка: 6 (1)
Здравствуйте, VladD2, Вы писали:

BZ>>а какие у вас объёмы?


VD>Последний бэкап был 35 гиг, к сожалению .


80 гиг домашней серии стоят $1000, 64 гига серверной — $2000

BZ>>насчёт скорости записи ты ошибаешься. линейная скорость у домашнего накопителя меньше чем у винтов. iops даже у домашнего раз в 5 выше 15-тысячников


VD>iops — это seek?


i/o operations per second. т.е. на паттерне субд он вдесятеро быстрее. может, проще на ixbt азглянуть?

VD>Сик у SSD конечно неплохой, а вот скорость записи никакая. У нас на одном сервере был RAID 0 из четырех 15-тысячинков, на втором из двух 10-тысячников. В общем-то объем памяти компенсирует скорость винтов с лихвой. Память по любому быстрее любых SSD.


если мало записи и все данные влезают в память, то да
Люди, я люблю вас! Будьте бдительны!!!
Re[2]: диалог с любителями потоков
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 04.07.09 19:18
Оценка: 3 (1)
Здравствуйте, minorlogic, Вы писали:

M>Попробую высказать крамольную мысль. Если програмировать в терминах "пускать эту задачу в отдельном потоке или нет" то далеко не уедешь. Не получишь по настоящему масштабируемую систему. Не сможешь запустить как на winCE так и на высоконагруженном сервере.


M>А если думать о решаемой задаче в отрыве от к-ва потоков? пускай к-вом потоков заведует кто то другой, конфиг например. А нам то зачем закладываться на то в каком мы потоке крутимся? Собственно знание о том в каком мы потоке и без того увеличивает связанность данных.


M>Вывод : ответь себе на вопрос, а стоит ли в прикладном коде каким бы то ни было способом закладываться на исполняющий поток ?


К сожалению, стоит. Например, простейший случай — некое библиотечное средство работает только с той нитью, из которой его инициализировали. Мне приходится иметь дело с библиотеками доступа к базе данных, которые имеют такие ограничения. Или, например, в Erlang стандартной практикой является привязка ETS (хэш-таблицы в памяти) или порта (такого, как открытый сокет) к одному процессу, который назначен владельцем: только владелец порта имеет право писать в него и только он получает сообщения из него. Менять владельца иногда можно, но геморройно.

Это случай внешних ограничений, но даже без них достаточно часто оказывается ряд факторов внутреннего порядка. Опять-таки, если мы знаем, что с каким-то ресурсом работает только одна нить, можно сократить затраты на локинг. Я постоянно сталкиваюсь с проблемами подобного рода, но трудно сформулировать достаточно внятный пример, не зависящий от задачи.

Ваше предложение достаточно часто реализуется в том случае, если работу можно формализовать в терминах заданий и их исполнителей. Исполнителями назначаются пулы ниток, в конфиге выставляются настроечные параметры этих пулов (типа initial, max, min_spare, max_spare), и далее всё просто и прямолинейно — задание формулируется в виде сообщения, кладётся во входную очередь пула, дальше его отработают и сформируют другие сообщения, которые могут быть обработаны другими пулами. Разделяя типы заданий по пулам, можно подобрать адекватное разделение нагрузки по внутренним видам. Настраивая параметры, можно разрешать как безудержный рост, так и сильное лимитирование. Данные хранятся в общей памяти и блокируются стандартными механизмами. Под такую обстановку писать — крайне удобно и просто, вопросов нет:) Только FSM'ы нарисовать надо, если где-то внешнее ожидание.

Всё это я к тому, что "знание о том, в каком мы потоке" в Вашей терминологии почему-то приобрело дополнительное значение "в котором по счёту". Это действительно не важно, важно другое: например (простой, но понятный случай) знание и гарантия того, что нить, исполняющая какой-то код (1), не та же, что нить, исполняющая (2), независимо от того, как легли карты и что выдал генератор случайных чисел. В этом смысле "в каком мы потоке" крайне важно. Если нить A ждёт ответа на задание Y, которое отдано на вход очереди той же нити A, работы не будет. Если другой — будет.

(Несколько сумбурно описал, но идея должна быть понятна.)
The God is real, unless declared integer.
Re[21]: диалог с любителями потоков
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.07.09 03:59
Оценка: 2 (1)
Здравствуйте, Mr.Cat, Вы писали:
MC>А скорость записи у ssd все еще деградирует со временем или уже нет?
Конечно же деградирует. Первая ось, в которой решили проблему с деградацией — Win7. А она еще не вышла.
Ну, и, конечно, надо понимать, что последовательные перезаписи по-любому убивают SSD.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
диалог с любителями потоков
От: sluge  
Дата: 01.07.09 06:09
Оценка: :)
постоянно сталкиваюсь с персонажами, которых я про себя называю "любители потоков". Этих людей отличает то что они для любой функциональности считают нужным заводить отдельный поток. И ладно еще если этих потоков будет гораниченное число-например поток на работу с сетью, поток на работу с БД. Бывает так что скажем хочет человек написать web-сервер и говорит-а дай ка я на каждое соединение заведу себе поток. Потом следуя своей стратегии, на каждое соединение заводится 2,3 и так далее потоков. Таким образом получается что при скажем 1000 соединений в системе будет 1000*n потоков. Кто что думает по этому поводу, и есть ли тут такие любители потоков?
Re[4]: диалог с любителями потоков
От: CreatorCray  
Дата: 01.07.09 08:14
Оценка: +1
Здравствуйте, SkyDance, Вы писали:

SD>В С++, особливо на виндах, — проблема.

SD> Стек на 1000 процессов выест 1000 * 10 Мб (по дефолту) = 10 Гб виртуальной памяти, в 32 бита (2 Гб предел) уже не лезет.
А при чем тут вообще С++?
CreateThread — WinAPI функция, которой можно задавать отличный от дефолтного размер стека.

SD> Проблема реально существует, мы с ней боролись. Сначала уменьшением аппетитов (до 1 Мб стека), потом стало понятно, что делу это не поможет и консолидировали потоки. Стало намного лучше работать.

Можно было попробовать еще на Fiber-ы перенести, некоторым помогало.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[2]: диалог с любителями потоков
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.07.09 13:35
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

S>А если есть желание написать сервер, который будет держать хотя бы десятки тысяч клиентов, то, конечно же, выделять отдельный поток на соединение нельзя.


IIS вроде бы выделяет, но все им пользуются тем не менее.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: диалог с любителями потоков
От: Курилка Россия http://kirya.narod.ru/
Дата: 03.07.09 11:19
Оценка: :)
Здравствуйте, Gomes, Вы писали:

G>Здравствуйте, Курилка, Вы писали:


К>>Обычные потоки уровня операционки, а поверх и там и там message-passing, правда в Эрланге много приятней.

G>Причем тут потоки? С сокетами какая модель работы?

если про сокеты, то, видимо, ты будешь прав, только всё равно эрланг не использует IOCP (но используется epoll, /dev/poll etc.), но причина, видимо, в том, что люди виндой не пользуются/
Re[8]: диалог с любителями потоков
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 08.07.09 08:34
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, VladD2, Вы писали:

VD>>Издеваешься что ли? 10 потоков на проц это очень даже не мало.
S>Нормально. В ASP.NET по умолчанию 25.
VD>>На большинстве сайтов 10 параллельных запросов — это уже много.
VD>>Потом, что будет если у нас пользователей больше чем 10, а проц один? Они пойдут в очередь? Офигительный параллелизм.
S>Совершенно верно — офигительный.
S>Потому что при IOCP потоки пула никогда не блокируются на вводе/выводе. Вместо этого они подхватывают следующий запрос и выполняют его.
S>Веб-сервер — это I/O Bound работа. Потому что латентность сети очень высока. Так что десять потоков могут окучить огромное количество одновременно открытых сокетов.

У меня есть подозрение, что вы говорите немного о разном — о задаче "сформировать контент" (которая плохо ложится на событийно-коллбэковую организацию, требуюмую при IOCP) и "отдать уже сформированный контент" (которая как раз на него практически идеально ложится). Делать, чтобы они обе исполнялись в одной и той же подзадаче (нити, процессе) оказывается легко в написании, но неэффективно при существенной нагрузке: переключения контекстов подзадач слишком дороги.

В случае их разделения можно делать для отработки по сути функции — "стрелкИ" (в смысле, "получил команду — выстрелил — забыл"), а отдачу результата возложить уже на другой слой, которому организация на IOCP, poll/kqueue/etc. и прочих событийно-управляемых "по мелочи" движках прописана по определению.

В Unix мире это реализуется несколькими путями, к которым можно привести классические примеры:

1. Отдельно стоящий кэширующий и отдающий процесс-сервер, забирающий данные крупными порциями, обычно сейчас это nginx. У него событийно-управляемое построение и задачу "передать следующую порцию данных" он решает лучше сложного сервера. Дополнительно можно получить от этого несколько вкусностей: сокрытие внутренней сети, лёгкая отдача статического контента.

2. Accept filter в ядре (FreeBSD) и аналогичные средства других систем: HTTP accept filter на сокете не выдаёт результат accept() в userland до тех пор, пока не наберётся полный HTTP запрос (есть два варианта фильтра — только по заголовкам или по телу тоже), после чего процесс сервера может получить запрос за один вызов. На специфических задачах вроде того же прокси-фронтэнда ускорение от этого может быть в разы, на "обобщённых на все случаи" серверах вроде Apache — меньше, но тоже заметно.

Повторюсь — с использованием таких средств ситуация что "веб-сервер зависит от латентности сети" как-то уходит:)

Краем уха слышал, что в IIS применяются похожие подходы, но не буду давать даже треть зуба за это:)

VD>>По уму в веб-сервере должны поддерживаться легкие потоки (а-ля Эрланг) и на каждый запрос выделяться по такому клиенту, а уже они должны распределяться между процессорами.

S>Ты, наверное, не в курсе, что такое I/O Completion Port? Это и есть что-то типа лёгких потоков, только программировать их не так удобно.

В данном случае "не так удобно" может вылиться в колоссальные недостатки, если сравнить необходимость рисования FSM с возможностью линейного написания действий в духе "получил A, передал B, получил ответ, отдал C".

S>Вот Рихтер придумал библиотечку для .Net, которая даёт улучшенный API к IOCP — по сравнению с ручным программированием коллбэков и протаскиванием состояния.


URL? Пределы возможностей?
The God is real, unless declared integer.
Re[8]: диалог с любителями потоков
От: VladD2 Российская Империя www.nemerle.org
Дата: 08.07.09 16:02
Оценка: -1
Здравствуйте, Sinclair, Вы писали:

S>Потому что при IOCP потоки пула никогда не блокируются на вводе/выводе. Вместо этого они подхватывают следующий запрос и выполняют его.

S>Веб-сервер — это I/O Bound работа. Потому что латентность сети очень высока. Так что десять потоков могут окучить огромное количество одновременно открытых сокетов.

Про сокеты речи и не шало. Речь шла о праллельных запросах. И более 10 их окучить не удастся. При этом будет не хилый оверхэд на переключение контекста.

Почитай про эрланг. Для него (хотя язык интерпретатор) и 1000 праллельно работающих задач — это нормально.

VD>>Это свидетельствует только о том, что технологии не дотягивают.

S>Технологии дотягивают. Влад, я тебя уверяю — ты вспотеешь рвать IIS по производительности.

А меня и уверять не надо. Я и так заню, что подход фиговенький.

VD>>По уму в веб-сервере должны поддерживаться легкие потоки (а-ля Эрланг) и на каждый запрос выделяться по такому клиенту, а уже они должны распределяться между процессорами.

S>Ты, наверное, не в курсе, что такое I/O Completion Port? Это и есть что-то типа лёгких потоков, только программировать их не так удобно.

В курсе. Это не потоки, это фигня. Это способ асинхронной обработки IO.

S>Вот Рихтер придумал библиотечку для .Net, которая даёт улучшенный API к IOCP — по сравнению с ручным программированием коллбэков и протаскиванием состояния.


Это все козьи потягушки.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: диалог с любителями потоков
От: EvilChild Ниоткуда  
Дата: 11.07.09 14:30
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Тут все, как бы, очень просто. Для работы программисту удобнее чтобы каждый отдельный запрос выполнялся бы в отдельном потоке или процессе. Если поток/процесс дешев, то это отличное решение, причем, не требующее дополнительных оптимизаций. Но потоки в современных ОС не дешевы. Переключение контекста дорогое удовольствие. Причем чем больше переключений (т.е. больше потоков) тем дороже.


Программисту скорее удобнее, чтобы код можно было писать в последовательном стиле.
Чтобы этого добиться необязательно заводить по потоку на обработку запроса.
Можно писать последовательный код, который потом компилятор подвергнет CPS преобразованию (см. Kilim и вроде Axum так же поступает).
Nemerle в теории такое должно быть под силу с помощью макросов.
Если сходишь по ссылкам из соседнего поста про Kilim — расскажи по зубам ли им такая трансформация.
now playing: Heartthrob — Interference
Re[15]: диалог с любителями потоков
От: EvilChild Ниоткуда  
Дата: 13.07.09 19:31
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>А кто сказал что IO там главное и по делу? И кто сказал, что всегда и везде IO занимает основное время?


VD>К тому же что означает IO? Вот я нажимаю на ссылочку "Мой RSDN\Ответы мне" и сайт начинает безбожно тормозить. Это IO виноват? Мне кажется, что IO — это тоже вычисления в массе своей. Пользователю же важно чтобы он по быстрее получил отклик, а не то чем занят процессор сервера. А раз так то нам нужны более пораллельные решения которые обрабатывают данные более интеллектуально. И здесь мне кажется, идея обработки запросов пользователей в легких процессах намного лучше идеи возни с комплешон-портами, пулами потоков и в итоге с массовым переключением контекста потоков.


Я не в курсе как устроен сайт, но есть подозрение, что по нажатию тобой кнопки происходит запрос к серверу БД,
база небось на диске хранится к которому надо сходить, что суть IO.
Формирование HTTP ответа просто ерунда по сравнению с этим — какие там вычисления то?
Так что львиную долю времени твой запрос проводит в ожидании ответа от диска.
Наверняка там есть индексы, ядро держит в кэше куски БД, но это как раз оптимизации цель которых снизить стоимость этого самого IO.
now playing: Oliver Koletzki — Nascita Of The Monsters (Martin Patino Remix)
Re[21]: диалог с любителями потоков
От: BulatZiganshin  
Дата: 15.07.09 22:24
Оценка: -1
Здравствуйте, VladD2, Вы писали:

VD>Сик у SSD конечно неплохой, а вот скорость записи никакая.


да, ты видимо просто не читал про intel ssd. они в разы опережают то, про что ты читал
Люди, я люблю вас! Будьте бдительны!!!
Re[22]: диалог с любителями потоков
От: Mr.Cat  
Дата: 16.07.09 07:15
Оценка: +1
Здравствуйте, Sinclair, Вы писали:
S>Конечно же деградирует. Первая ось, в которой решили проблему с деградацией — Win7. А она еще не вышла.
А где можно почитать, как решили?
Re[27]: диалог с любителями потоков
От: Слоноежик  
Дата: 28.07.09 12:29
Оценка: :)
Здравствуйте, VladD2, Вы писали:

VD>Дешевые это те что за 1000 баксов? А в дорогих говоришь кэш есть? Ну, так за эту 1000 баксов можно столько памяти купить...

Дешёвые это которые гуглятся по словамnetbook ssd
для забивания гвоздя надо выбирать правильный микроскоп.
Re: диалог с любителями потоков
От: Mr.Cat  
Дата: 01.07.09 06:17
Оценка:
А why, собственно, и not? Эрланг же.
Re[2]: диалог с любителями потоков
От: sluge  
Дата: 01.07.09 06:29
Оценка:
Здравствуйте, Mr.Cat, Вы писали:

MC>А why, собственно, и not? Эрланг же.


а если с++ или жаба?
Re: диалог с любителями потоков
От: Sinclair Россия https://github.com/evilguest/
Дата: 01.07.09 06:54
Оценка:
Здравствуйте, sluge, Вы писали:

S>постоянно сталкиваюсь с персонажами, которых я про себя называю "любители потоков". Этих людей отличает то что они для любой функциональности считают нужным заводить отдельный поток. И ладно еще если этих потоков будет гораниченное число-например поток на работу с сетью, поток на работу с БД. Бывает так что скажем хочет человек написать web-сервер и говорит-а дай ка я на каждое соединение заведу себе поток. Потом следуя своей стратегии, на каждое соединение заводится 2,3 и так далее потоков. Таким образом получается что при скажем 1000 соединений в системе будет 1000*n потоков. Кто что думает по этому поводу, и есть ли тут такие любители потоков?

А что, тут какие-то варианты мнений что ли есть? Если у людей нет желания написать масштабируемый сервер массового обслуживания — то пусть делают как хотят. Некоторые и вообще удовлетворяются одноклиентными серверами.
А если есть желание написать сервер, который будет держать хотя бы десятки тысяч клиентов, то, конечно же, выделять отдельный поток на соединение нельзя.

Вообще, интересно, где это вы "постоянно сталкиваетесь" с такими персонажами.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: диалог с любителями потоков
От: SkyDance Земля  
Дата: 01.07.09 07:55
Оценка:
S>а если с++ или жаба?

В С++, особливо на виндах, — проблема. Стек на 1000 процессов выест 1000 * 10 Мб (по дефолту) = 10 Гб виртуальной памяти, в 32 бита (2 Гб предел) уже не лезет. Проблема реально существует, мы с ней боролись. Сначала уменьшением аппетитов (до 1 Мб стека), потом стало понятно, что делу это не поможет и консолидировали потоки. Стало намного лучше работать.
Re[2]: диалог с любителями потоков
От: frogkiller Россия  
Дата: 01.07.09 08:42
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>А что, тут какие-то варианты мнений что ли есть? Если у людей нет желания написать масштабируемый сервер массового обслуживания — то пусть делают как хотят. Некоторые и вообще удовлетворяются одноклиентными серверами.

S>А если есть желание написать сервер, который будет держать хотя бы десятки тысяч клиентов, то, конечно же, выделять отдельный поток на соединение нельзя.

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

А вообще мой пойнт такой, что в даже рамках одного проекта могут быть разные сервера с разными потоковыми моделями.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Re[2]: диалог с любителями потоков
От: Gomes Россия http://irazin.ru
Дата: 01.07.09 10:47
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>А если есть желание написать сервер, который будет держать хотя бы десятки тысяч клиентов, то, конечно же, выделять отдельный поток на соединение нельзя.

S>Вообще, интересно, где это вы "постоянно сталкиваетесь" с такими персонажами.
Ща рассмешу: здесь
Автор: Gomes
Дата: 13.02.09

Там по ветке есть ссылка на скачку видео.
Re[6]: диалог с любителями потоков
От: jedi Мухосранск  
Дата: 01.07.09 11:36
Оценка:
Здравствуйте, SkyDance, Вы писали:

SD>Старые legacy, когда там уже мегатонны древючего кода намучены, рефакторить в таком объеме было просто "ссыкотно" (С).


В чем тогда заключалось "консолидировали потоки" ? и почему это было менее "ссыкотно" (С)
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
Re[6]: диалог с любителями потоков
От: CreatorCray  
Дата: 01.07.09 11:37
Оценка:
Здравствуйте, SkyDance, Вы писали:

SD>Потому что в жабе потоки сразу обычно легковесные — и без всяких CreateThread.

Видимо потому, что они не совсем потоки. Вернее не OS потоки.

SD>Старые legacy, когда там уже мегатонны древючего кода намучены, рефакторить в таком объеме было просто "ссыкотно" (С).

+1
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[7]: диалог с любителями потоков
От: Курилка Россия http://kirya.narod.ru/
Дата: 01.07.09 11:52
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, SkyDance, Вы писали:


SD>>Потому что в жабе потоки сразу обычно легковесные — и без всяких CreateThread.

CC>Видимо потому, что они не совсем потоки. Вернее не OS потоки.
В яве зелёные потоки были насколько мне помнится только в 1.1.
Re[7]: диалог с любителями потоков
От: SkyDance Земля  
Дата: 01.07.09 11:54
Оценка:
J>В чем тогда заключалось "консолидировали потоки" ? и почему это было менее "ссыкотно" (С)

Проект старый, начат был малоквалифицированными людьми. Каждый громоздил свой слой абстрации от чего-нибудь, и дописывал наслоения кода. Так вот, при таком количестве кода нетрудно было найти точки диспетчеризации для наиболее типичных задач, которые порождали наибольшее количество потоков. Соответственно, часть потоков стала консолидироваться через один диспетчер. Это позволило нам расширить поддержку многосерверных инсталляций до нескольких сотен серверов. До этого, когда был thread per server, мы были ограничены примерно 130 серверами в постоянном мониторинге. И в целом, когда мы проводили исследования, даже при сниженном объеме стека до 256 кб у нас не создавалось больше 190 потоков. То ли из-за фрагментации памяти, то ли еще почему, но — факт.

Решение, конечно, местечковое. Но именно такие и принимаются во время maintenance продукта — никто не будет проводить глобальный рефакторинг, если это не принесет реальных бенефитов.
Re[4]: диалог с любителями потоков
От: sluge  
Дата: 02.07.09 07:21
Оценка:
Здравствуйте, SkyDance, Вы писали:

S>>а если с++ или жаба?


SD>В С++, особливо на виндах, — проблема. Стек на 1000 процессов выест 1000 * 10 Мб (по дефолту) = 10 Гб виртуальной памяти, в 32 бита (2 Гб предел) уже не лезет. Проблема реально существует, мы с ней боролись. Сначала уменьшением аппетитов (до 1 Мб стека), потом стало понятно, что делу это не поможет и консолидировали потоки. Стало намного лучше работать.


а что значит консолидировали потоки?
Re[3]: диалог с любителями потоков
От: Sinclair Россия https://github.com/evilguest/
Дата: 03.07.09 02:33
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>IIS вроде бы выделяет, но все им пользуются тем не менее.
Ну конечно же ничего он не выделяет. Он использует IO Completion Ports и пул потоков.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re: диалог с любителями потоков
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.07.09 07:59
Оценка:
Здравствуйте, sluge, Вы писали:

S>постоянно сталкиваюсь с персонажами, которых я про себя называю "любители потоков". Этих людей отличает то что они для любой функциональности считают нужным заводить отдельный поток. И ладно еще если этих потоков будет гораниченное число-например поток на работу с сетью, поток на работу с БД. Бывает так что скажем хочет человек написать web-сервер и говорит-а дай ка я на каждое соединение заведу себе поток. Потом следуя своей стратегии, на каждое соединение заводится 2,3 и так далее потоков. Таким образом получается что при скажем 1000 соединений в системе будет 1000*n потоков. Кто что думает по этому поводу, и есть ли тут такие любители потоков?


Ежу понятно:)), что всё зависит от задачи. И от среды.

Есть примеры, когда подход "одна нить на клиента" приводила к переполнению ресурсов — например, oops (конкурент squid'а) выдерживал более 2000 клиентов только на солярке, а на более "народных" ОС дох значительно раньше. Соответственно, он далеко не ушёл.

Но чем сложнее обработка и чем меньше клиентов, тем проще и осмысленнее делать по нити на клиента и даже по несколько нитей на клиента.

P.S. В качестве бесстыдной рекламы, FAQ по этим вопросам для Unix. Основные идеи, однако, годятся для любой ОС.
The God is real, unless declared integer.
Re[2]: диалог с любителями потоков
От: Gomes Россия http://irazin.ru
Дата: 03.07.09 08:32
Оценка:
Здравствуйте, netch80, Вы писали:

N>P.S. В качестве бесстыдной рекламы, FAQ по этим вопросам для Unix. Основные идеи, однако, годятся для любой ОС.

Не знаю как там под юниксами, но под виндами — либо, в простейшем случае, по потоку на клиента, либо IOCP. Все остальное вредно для здоровья и душевного равновесия. А то, что в юниксах такой зоопарк — разработчикам можно только посочувствовать, и пожелать скорейшего перехода на единую нормальную технологию.
Re[3]: диалог с любителями потоков
От: Курилка Россия http://kirya.narod.ru/
Дата: 03.07.09 09:11
Оценка:
Здравствуйте, Gomes, Вы писали:

G>Здравствуйте, netch80, Вы писали:


N>>P.S. В качестве бесстыдной рекламы, FAQ по этим вопросам для Unix. Основные идеи, однако, годятся для любой ОС.

G>Не знаю как там под юниксами, но под виндами — либо, в простейшем случае, по потоку на клиента, либо IOCP. Все остальное вредно для здоровья и душевного равновесия. А то, что в юниксах такой зоопарк — разработчикам можно только посочувствовать, и пожелать скорейшего перехода на единую нормальную технологию.

Т.е. если я запущу сервер на Эрланг с числом потоков по числу ядер, то это вредно для здоровья и моего душевного равновесия? Или вот, когда я работал в конторе, где писали софт для телекома на Java, и оно вполне работало на винде, не беря по потоку на коннект — это тоже было себе и клиентам назло?
(виндовые машины были у разработчиков, хоть и не у всех, в реальных условиях оно не на винде работало, конечно)
Re[4]: диалог с любителями потоков
От: Gomes Россия http://irazin.ru
Дата: 03.07.09 09:20
Оценка:
Здравствуйте, Курилка, Вы писали:

К>Т.е. если я запущу сервер на Эрланг с числом потоков по числу ядер, то это вредно для здоровья и моего душевного равновесия? Или вот, когда я работал в конторе, где писали софт для телекома на Java, и оно вполне работало на винде, не беря по потоку на коннект — это тоже было себе и клиентам назло?

К>(виндовые машины были у разработчиков, хоть и не у всех, в реальных условиях оно не на винде работало, конечно)
Ты о чем вообще? Вот это все хозяйство внутри себя что использует?
Re[5]: диалог с любителями потоков
От: Курилка Россия http://kirya.narod.ru/
Дата: 03.07.09 09:25
Оценка:
Здравствуйте, Gomes, Вы писали:

G>Здравствуйте, Курилка, Вы писали:


К>>Т.е. если я запущу сервер на Эрланг с числом потоков по числу ядер, то это вредно для здоровья и моего душевного равновесия? Или вот, когда я работал в конторе, где писали софт для телекома на Java, и оно вполне работало на винде, не беря по потоку на коннект — это тоже было себе и клиентам назло?

К>>(виндовые машины были у разработчиков, хоть и не у всех, в реальных условиях оно не на винде работало, конечно)
G>Ты о чем вообще? Вот это все хозяйство внутри себя что использует?

На пальцах объясняю: ни Эрланг, ни JVM не создают по потоку на клиента и не используют IOCP. У эрланга (как я уже писал) создаётся по потоку на ядро, в JVM (в том сервере) создаётся конечное число потоков (определяемое конфигурацией и, скорее всего также, соответсвующее числу ядер)
Re[6]: диалог с любителями потоков
От: Gomes Россия http://irazin.ru
Дата: 03.07.09 09:29
Оценка:
Здравствуйте, Курилка, Вы писали:

К>На пальцах объясняю: ни Эрланг, ни JVM не создают по потоку на клиента и не используют IOCP.

А что они используют? И почему они не используют IOCP?
Re[7]: диалог с любителями потоков
От: Курилка Россия http://kirya.narod.ru/
Дата: 03.07.09 09:45
Оценка:
Здравствуйте, Gomes, Вы писали:

G>Здравствуйте, Курилка, Вы писали:


К>>На пальцах объясняю: ни Эрланг, ни JVM не создают по потоку на клиента и не используют IOCP.

G>А что они используют? И почему они не используют IOCP?
Обычные потоки уровня операционки, а поверх и там и там message-passing, правда в Эрланге много приятней.
Re[8]: диалог с любителями потоков
От: Gomes Россия http://irazin.ru
Дата: 03.07.09 09:49
Оценка:
Здравствуйте, Курилка, Вы писали:

К>Обычные потоки уровня операционки, а поверх и там и там message-passing, правда в Эрланге много приятней.

Причем тут потоки? С сокетами какая модель работы?
Re[9]: диалог с любителями потоков
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 03.07.09 11:32
Оценка:
Здравствуйте, Gomes, Вы писали:

G>Здравствуйте, Курилка, Вы писали:


К>>Обычные потоки уровня операционки, а поверх и там и там message-passing, правда в Эрланге много приятней.

G>Причем тут потоки? С сокетами какая модель работы?

Сокет посылает сообщение процессу-владельцу, как только в него поступают данные. Остановить это, кстати, AFAIK нельзя:) Насколько это похоже на IOCP, судите сами;) Или речь о том, что там внутри? В виндовом варианте может быть и IOCP, но прикладному программисту эти тонкости не видны.
The God is real, unless declared integer.
Re[10]: диалог с любителями потоков
От: Gomes Россия http://irazin.ru
Дата: 03.07.09 12:00
Оценка:
Здравствуйте, Курилка, Вы писали:

К>если про сокеты, то, видимо, ты будешь прав,

Дык это в моем первом сообщении и было. Это ж очевидно

К>только всё равно эрланг не использует IOCP (но используется epoll, /dev/poll etc.), но причина, видимо, в том, что люди виндой не пользуются/

Re[10]: диалог с любителями потоков
От: Gomes Россия http://irazin.ru
Дата: 03.07.09 12:04
Оценка:
Здравствуйте, netch80, Вы писали:

N>Или речь о том, что там внутри?

Не понимаю о чем разговор, в моем сообщении всё (всё) очевидно Да, внутри.
Re[4]: диалог с любителями потоков
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.07.09 16:57
Оценка:
Здравствуйте, Sinclair, Вы писали:

VD>>IIS вроде бы выделяет, но все им пользуются тем не менее.

S>Ну конечно же ничего он не выделяет. Он использует IO Completion Ports и пул потоков.

И что в итоге выходит на одного активного клиента?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: диалог с любителями потоков
От: gear nuke  
Дата: 04.07.09 05:44
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>И что в итоге выходит на одного активного клиента?


Запусти ProcessExplorer, и посмотри, сколько тредов у процесса system имеет стартовый адрес в http.sys (по крайней мере один из них — сборщик мусора).

Приложениям же достаточно одного треда на очередь HTTP запросов. Одна очередь способна обрабатывать запросы к нескольким URL от (почти) произвольного количества клиентов.
.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
Re[11]: диалог с любителями потоков
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 04.07.09 07:21
Оценка:
Здравствуйте, Gomes, Вы писали:

G>Здравствуйте, netch80, Вы писали:


N>>Или речь о том, что там внутри?

G>Не понимаю о чем разговор, в моем сообщении всё (всё) очевидно ;) Да, внутри.

Не очевидно.
Erlang создавался на embedded платформе Unix стиля и до сих пор активно на винду не переносился. Может, сейчас начнут.
The God is real, unless declared integer.
Re: диалог с любителями потоков
От: minorlogic Украина  
Дата: 04.07.09 11:04
Оценка:
Здравствуйте, sluge, Вы писали:

S>постоянно сталкиваюсь с персонажами, которых я про себя называю "любители потоков". Этих людей отличает то что они для любой функциональности считают нужным заводить отдельный поток. И ладно еще если этих потоков будет гораниченное число-например поток на работу с сетью, поток на работу с БД. Бывает так что скажем хочет человек написать web-сервер и говорит-а дай ка я на каждое соединение заведу себе поток. Потом следуя своей стратегии, на каждое соединение заводится 2,3 и так далее потоков. Таким образом получается что при скажем 1000 соединений в системе будет 1000*n потоков. Кто что думает по этому поводу, и есть ли тут такие любители потоков?


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

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

Вывод : ответь себе на вопрос, а стоит ли в прикладном коде каким бы то ни было способом закладываться на исполняющий поток ?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[12]: диалог с любителями потоков
От: Gomes Россия http://irazin.ru
Дата: 04.07.09 14:47
Оценка:
Здравствуйте, netch80, Вы писали:

N>Не очевидно.

КАК НАМ ВСЕМ НАУЧИТЬСЯ ЧИТАТЬ, ЧТО НАПИСАНО?

"Не знаю как там под юниксами, но под виндами — ..."
Re[13]: диалог с любителями потоков
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 04.07.09 19:02
Оценка:
Здравствуйте, Gomes, Вы писали:

G>Здравствуйте, netch80, Вы писали:


N>>Не очевидно.

G>КАК НАМ ВСЕМ НАУЧИТЬСЯ ЧИТАТЬ, ЧТО НАПИСАНО?

G>"Не знаю как там под юниксами, но под виндами — ..."


"Я читал какой-то текст этого автора! Кажется, я знаю, что здесь написано!" (из Вашей же ссылки)

Что это были разные сообщения и в них может идти речь совершенно о разном — видите?
The God is real, unless declared integer.
Re[3]: диалог с любителями потоков
От: minorlogic Украина  
Дата: 04.07.09 19:26
Оценка:
Здравствуйте, netch80, Вы писали:

N>Ваше предложение достаточно часто реализуется в том случае, если работу можно формализовать в терминах заданий и их исполнителей. Исполнителями назначаются пулы ниток, в конфиге выставляются настроечные параметры этих пулов (типа initial, max, min_spare, max_spare), и далее всё просто и прямолинейно — задание формулируется в виде сообщения, кладётся во входную очередь пула, дальше его отработают и сформируют другие сообщения, которые могут быть обработаны другими пулами. Разделяя типы заданий по пулам, можно подобрать адекватное разделение нагрузки по внутренним видам. Настраивая параметры, можно разрешать как безудержный рост, так и сильное лимитирование. Данные хранятся в общей памяти и блокируются стандартными механизмами. Под такую обстановку писать — крайне удобно и просто, вопросов нет Только FSM'ы нарисовать надо, если где-то внешнее ожидание.


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

N>Всё это я к тому, что "знание о том, в каком мы потоке" в Вашей терминологии почему-то приобрело дополнительное значение "в котором по счёту". Это действительно не важно, важно другое: например (простой, но понятный случай) знание и гарантия того, что нить, исполняющая какой-то код (1), не та же, что нить, исполняющая (2), независимо от того, как легли карты и что выдал генератор случайных чисел. В этом смысле "в каком мы потоке" крайне важно. Если нить A ждёт ответа на задание Y, которое отдано на вход очереди той же нити A, работы не будет. Если другой — будет.


совершенно согласен , но как я описал это ограничение намного меньше чем "задача должна крутиться в одном потоке". Просто определенный клас задач мы можем пометить как исполняемые в одном потоке. Даже больше, можно метить задачи атрибутами важности, блокирующие неблокирующие и т.п.

Система все еще отстается достаточно расширяемой.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Ищу работу, 3D, SLAM, computer graphics/vision.
Re[3]: диалог с любителями потоков
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 04.07.09 19:41
Оценка:
Здравствуйте, Gomes, Вы писали:

G>Здравствуйте, netch80, Вы писали:


N>>P.S. В качестве бесстыдной рекламы, FAQ по этим вопросам для Unix. Основные идеи, однако, годятся для любой ОС.


G>Не знаю как там под юниксами, но под виндами — либо, в простейшем случае, по потоку на клиента, либо IOCP. Все остальное вредно для здоровья и душевного равновесия. А то, что в юниксах такой зоопарк — разработчикам можно только посочувствовать, и пожелать скорейшего перехода на единую нормальную технологию.


Про "нормальную технологию", если уж вдаваться в эти детали — kqueue и epoll представляют собой полный аналог IOCP, особенно первый (если учесть EVFILT_AIO). Только по сравнению с Windows, у kqueue и вообще построения работы с файловыми объектами в Unix есть существенное преимущество: нет принудительного неустранимого навязывания асинхронного стиля при открытии; независимо от того, откуда и как ты получил дескриптор — ты можешь, если хочешь, работать по старинке блокирующими вызовами, можешь — через полное AIO, можешь — через общий мультиплексор типа select. В Windows такой гибкости нет.

Смутное преимущество виндовых IOCP состоит в том, что, если верить MSDN, поместить в них сообщение может каждый, а не только ядро. Но не думаю, что кому-то есть смысл делать из IOCP очередь сообщений уровня userland.

Ну а здоровье и душевное равновесие мы успешно получаем применением библиотек, которые в зависимости от возможностей платформы сами выбирают адекватное средство. С учётом того, что платформа вообще более спокойна (меньше странностей, неизвестных средств с отвратительной документацией и недокументированными особенностями), мне кажется, что моё, как программиста под Unix, душевное равновесие куда стабильнее, чем у среднего коллеги под Windows:)
The God is real, unless declared integer.
Re[4]: диалог с любителями потоков
От: Gomes Россия http://irazin.ru
Дата: 06.07.09 07:42
Оценка:
Здравствуйте, netch80, Вы писали:

N>Про "нормальную технологию", если уж вдаваться в эти детали — kqueue и epoll представляют собой полный аналог IOCP

Это хорошо. Только почему их так неохотно используют? "Линус Торвальдс его необоснованно не любит." Почитал по твоей ссылке — ну полный же бардак. Настоящая демократия

N>Только по сравнению с Windows, у kqueue и вообще построения работы с файловыми объектами в Unix есть существенное преимущество: нет принудительного неустранимого навязывания асинхронного стиля при открытии; независимо от того, откуда и как ты получил дескриптор — ты можешь, если хочешь, работать по старинке блокирующими вызовами, можешь — через полное AIO, можешь — через общий мультиплексор типа select. В Windows такой гибкости нет.

Оно, может, и полезно, но с наскоку придумать применение сложно. Ни разу не требовалось. Но согласен, лучше иметь возможность, чем не иметь.

N>Смутное преимущество виндовых IOCP состоит в том, что, если верить MSDN, поместить в них сообщение может каждый, а не только ядро. Но не думаю, что кому-то есть смысл делать из IOCP очередь сообщений уровня userland.

Ты про PostQueuedCompletionStatus? Это очень (очень) полезный функционал, используется постоянно.

N>Ну а здоровье и душевное равновесие мы успешно получаем применением библиотек, которые в зависимости от возможностей платформы сами выбирают адекватное средство. С учётом того, что платформа вообще более спокойна (меньше странностей, неизвестных средств с отвратительной документацией и недокументированными особенностями), мне кажется, что моё, как программиста под Unix, душевное равновесие куда стабильнее, чем у среднего коллеги под Windows

С библиотеками оно, конечно, понятно. Но если кто-то захочет узнать как оно внутри, то, пройдя по твоей ссылке, впадет в уныние
То ли дело под виндой!
Re[5]: диалог с любителями потоков
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 06.07.09 09:06
Оценка:
Здравствуйте, Gomes, Вы писали:

N>>Про "нормальную технологию", если уж вдаваться в эти детали — kqueue и epoll представляют собой полный аналог IOCP

G>Это хорошо. Только почему их так неохотно используют? "Линус Торвальдс его необоснованно не любит." Почитал по твоей ссылке — ну полный же бардак. Настоящая демократия :)

Потому что Windows — одна система, а юниксов несколько десятков (ну ладно, сейчас около 15 осталось развивающимися), и у каждого своя специфика. Ну а что при этом демократия и локальные амбиции — оно неудивительно, хотя всё равно в итоге всё выравнивается.

Насчёт "неохотно используют" — используют как раз охотно, там, где есть, потому что действительно удобно. И средства достаточно неплохие есть: например, в линуксе, где AIO не может сигнализировать в порт типа kqueue, можно вместо этого попросить посылать сигнал. Но и в BSD можно его попросить послать сигнал (посылка сигнала требуется по Posix), так что в результате всё равно есть общая база для реализации.

N>>Только по сравнению с Windows, у kqueue и вообще построения работы с файловыми объектами в Unix есть существенное преимущество: нет принудительного неустранимого навязывания асинхронного стиля при открытии; независимо от того, откуда и как ты получил дескриптор — ты можешь, если хочешь, работать по старинке блокирующими вызовами, можешь — через полное AIO, можешь — через общий мультиплексор типа select. В Windows такой гибкости нет.

G>Оно, может, и полезно, но с наскоку придумать применение сложно. Ни разу не требовалось. Но согласен, лучше иметь возможность, чем не иметь.

Применение как раз тривиально, если знать Unix. Есть масса ситуаций, когда процесс запускается имея на stdin и stdout предварительно открытые файлы (последовательного типа — пайпы или сокеты): например, вызов из-под inetd. Нужно, чтобы это работало независимо от того, будет ли он работать с ними просто синхронно, асинхронно через мультиплексор или асинхронно через IOCP.

N>>Смутное преимущество виндовых IOCP состоит в том, что, если верить MSDN, поместить в них сообщение может каждый, а не только ядро. Но не думаю, что кому-то есть смысл делать из IOCP очередь сообщений уровня userland.

G>Ты про PostQueuedCompletionStatus? Это очень (очень) полезный функционал, используется постоянно.

Например, зачем? И в чём преимущество по сравнению с просто очередью, учитывая то, что в PostQueuedCompletionStatus надо изображать из себя файловый объект и соответственно маскировать данные?

N>>Ну а здоровье и душевное равновесие мы успешно получаем применением библиотек, которые в зависимости от возможностей платформы сами выбирают адекватное средство. С учётом того, что платформа вообще более спокойна (меньше странностей, неизвестных средств с отвратительной документацией и недокументированными особенностями), мне кажется, что моё, как программиста под Unix, душевное равновесие куда стабильнее, чем у среднего коллеги под Windows:)

G>С библиотеками оно, конечно, понятно. Но если кто-то захочет узнать как оно внутри, то, пройдя по твоей ссылке, впадет в уныние ;)
G>То ли дело под виндой! :)) :beer:

Ну да, под виндой он сразу повесится и проблема отпадёт сама собой:)
The God is real, unless declared integer.
Re[6]: диалог с любителями потоков
От: Gomes Россия http://irazin.ru
Дата: 06.07.09 09:47
Оценка:
Здравствуйте, netch80, Вы писали:

N>Например, зачем? И в чём преимущество по сравнению с просто очередью, учитывая то, что в PostQueuedCompletionStatus надо изображать из себя файловый объект и соответственно маскировать данные?

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

N>Ну да, под виндой он сразу повесится и проблема отпадёт сама собой

ХОЛИВАР!!!
Под виндой все проще и понятнее! Потому как тоталитаризьм!
Re[7]: диалог с любителями потоков
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 06.07.09 10:38
Оценка:
Здравствуйте, Gomes, Вы писали:

N>>Например, зачем? И в чём преимущество по сравнению с просто очередью, учитывая то, что в PostQueuedCompletionStatus надо изображать из себя файловый объект и соответственно маскировать данные?

G>Посылать свои, например, управляющие коды в очередь обработчика. Например, чтобы завершить потоки пула. И не надо из себя изображать ни файловый ни какой другой объект.

Ну на kqueue это и так делается. А для остальных signal pipe достаточно дёшев:)

N>>Ну да, под виндой он сразу повесится и проблема отпадёт сама собой:)

G>ХОЛИВАР!!!
G>Под виндой все проще и понятнее! Потому как тоталитаризьм!

В *BSD тоже тоталитаризьма, но при этом можно всё увидеть простейшим образом:) Так что да, холивар:)
The God is real, unless declared integer.
Re[5]: диалог с любителями потоков
От: Sinclair Россия https://github.com/evilguest/
Дата: 07.07.09 06:34
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>И что в итоге выходит на одного активного клиента?
Трафик на него выходит, трафик
Пул потоков там очень маленький — порядка десятка потоков на одно ядро.
При этом "активных клиентов" могут быть десятки тысяч.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: диалог с любителями потоков
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 07.07.09 06:55
Оценка:
VD>>И что в итоге выходит на одного активного клиента?
S>Трафик на него выходит, трафик
S>Пул потоков там очень маленький — порядка десятка потоков на одно ядро.
S>При этом "активных клиентов" могут быть десятки тысяч.

Имхо это сложное управление потоками, а не отсутствие управления потоками. То, что люди с потоками работать не умеют, не является причиной их стратегической нецелесообразности, тем более учитывая нынешнее развитие технологий.
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[7]: диалог с любителями потоков
От: Sinclair Россия https://github.com/evilguest/
Дата: 07.07.09 07:25
Оценка:
Здравствуйте, VGn, Вы писали:
VGn>Имхо это сложное управление потоками, а не отсутствие управления потоками.
Я ничего не говорил про отсутствие управления потоками. Да, IOCP — достаточно сложная штука по сравнению с "простым" управлением потоками в стиле "1 поток на клиента".
VGn>То, что люди с потоками работать не умеют, не является причиной их стратегической нецелесообразности, тем более учитывая нынешнее развитие технологий.
Ну не знаю. Пока что мне непонятно, будут ли эти люди стратегически нецелесообразны, с учётом развития нынешних технологий.
Всё существенно зависит от стиля обучения. Пока люди думают о программировании как о задаче построения алгоритма, многопотоковость будет оставаться проблемой.
Потому что само определение алгоритма подразумевает единственного вычислителя, модифицирующего некое глобальное состояние. А если с самого начала обучать людей по-другому, то и результат будет другим.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[8]: диалог с любителями потоков
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 07.07.09 09:47
Оценка:
G>>Под виндой все проще и понятнее! Потому как тоталитаризьм!

N>В *BSD тоже тоталитаризьма, но при этом можно всё увидеть простейшим образом Так что да, холивар


Рекомендую одеть кастрюли на головы и отправиться в Священные войны
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[6]: диалог с любителями потоков
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.07.09 17:13
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Пул потоков там очень маленький — порядка десятка потоков на одно ядро.

S>При этом "активных клиентов" могут быть десятки тысяч.

Издеваешься что ли? 10 потоков на проц это очень даже не мало. На большинстве сайтов 10 параллельных запросов — это уже много.
Потом, что будет если у нас пользователей больше чем 10, а проц один? Они пойдут в очередь? Офигительный параллелизм.

Это свидетельствует только о том, что технологии не дотягивают. По уму в веб-сервере должны поддерживаться легкие потоки (а-ля Эрланг) и на каждый запрос выделяться по такому клиенту, а уже они должны распределяться между процессорами.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: диалог с любителями потоков
От: Sinclair Россия https://github.com/evilguest/
Дата: 08.07.09 02:55
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Издеваешься что ли? 10 потоков на проц это очень даже не мало.
Нормально. В ASP.NET по умолчанию 25.
VD>На большинстве сайтов 10 параллельных запросов — это уже много.
VD>Потом, что будет если у нас пользователей больше чем 10, а проц один? Они пойдут в очередь? Офигительный параллелизм.
Совершенно верно — офигительный.
Потому что при IOCP потоки пула никогда не блокируются на вводе/выводе. Вместо этого они подхватывают следующий запрос и выполняют его.
Веб-сервер — это I/O Bound работа. Потому что латентность сети очень высока. Так что десять потоков могут окучить огромное количество одновременно открытых сокетов.

VD>Это свидетельствует только о том, что технологии не дотягивают.

Технологии дотягивают. Влад, я тебя уверяю — ты вспотеешь рвать IIS по производительности.

VD>По уму в веб-сервере должны поддерживаться легкие потоки (а-ля Эрланг) и на каждый запрос выделяться по такому клиенту, а уже они должны распределяться между процессорами.

Ты, наверное, не в курсе, что такое I/O Completion Port? Это и есть что-то типа лёгких потоков, только программировать их не так удобно.
Вот Рихтер придумал библиотечку для .Net, которая даёт улучшенный API к IOCP — по сравнению с ручным программированием коллбэков и протаскиванием состояния.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[7]: диалог с любителями потоков
От: Gomes Россия http://irazin.ru
Дата: 08.07.09 04:53
Оценка:
Здравствуйте, VGn, Вы писали:

VGn>Имхо это сложное управление потоками, а не отсутствие управления потоками. То, что люди с потоками работать не умеют, не является причиной их стратегической нецелесообразности, тем более учитывая нынешнее развитие технологий.

О, эксперты подтянулись :)
Re[7]: диалог с любителями потоков
От: Gomes Россия http://irazin.ru
Дата: 08.07.09 05:01
Оценка:
Вот скажи, что заставляет высказывать подобное, абсолютно не разбираясь в теме? Лично я, если чуть в сторону от своей специализации — буду задавать вопросы и конспектировать. Так что, если что не понятно — спрашивай :)
Re[7]: диалог с любителями потоков
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 08.07.09 06:32
Оценка:
S>>Пул потоков там очень маленький — порядка десятка потоков на одно ядро.
S>>При этом "активных клиентов" могут быть десятки тысяч.

VD>Издеваешься что ли? 10 потоков на проц это очень даже не мало. На большинстве сайтов 10 параллельных запросов — это уже много.

VD>Потом, что будет если у нас пользователей больше чем 10, а проц один? Они пойдут в очередь? Офигительный параллелизм.

Поддерживаю. Заглянул тут в менеджер задач.
76 процессов. 894 потока. на 2х ядрах
И ничего. Не напрягается. (хотя задачи конечно десктопные и большинство в ожидании, но не суть)
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[8]: диалог с любителями потоков
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 08.07.09 06:41
Оценка:
G>Вот скажи, что заставляет высказывать подобное, абсолютно не разбираясь в теме? Лично я, если чуть в сторону от своей специализации — буду задавать вопросы и конспектировать. Так что, если что не понятно — спрашивай

Это IT. Здесь теряешь часть квалификации и за время кофе-брейка. Так что имхо не стоит задирать нос.
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[9]: диалог с любителями потоков
От: Sinclair Россия https://github.com/evilguest/
Дата: 09.07.09 03:16
Оценка:
Здравствуйте, netch80, Вы писали:

N>У меня есть подозрение, что вы говорите немного о разном — о задаче "сформировать контент" (которая плохо ложится на событийно-коллбэковую организацию, требуюмую при IOCP) и "отдать уже сформированный контент" (которая как раз на него практически идеально ложится).

Отличный поинт.
Давайте поймем, что такое "сформировать контент", и почему он так плохо ложится на событийную организацию.
Вообще говоря, современный динамический веб — это в 99% склеивание респонса из фрагментов. Как правило — строковых.
Само по себе склеивание определяется стоимостью строковых операций в использованной платформе.
А фрагменты берутся из файлов на диске, либо из СУБД. Иногда их тянут через сеть — к примеру, от внешнего SOAP/REST/etc сервиса.

Как видим, "формирование контента" — это лапша из некоторого количества IO-bound задач, которые склеиваются CPU-bound операциями конкатенации.
Еще 1% — это стуфф типа "ресайз картинок", в котором тоже значительная часть чистого времени уходит на собственно поднятие исходной картинки с диска.

Таким образом, из 1500 миллисекунд, которые нужны среднестатистическому хэндлеру на всё, он может проводить в летаргическом сне порядка 1000 миллисекунд — ожидая того или иного события. (Цифры — с потолка, для иллюстративных целей).

N>Делать, чтобы они обе исполнялись в одной и той же подзадаче (нити, процессе) оказывается легко в написании, но неэффективно при существенной нагрузке: переключения контекстов подзадач слишком дороги.


N>В случае их разделения можно делать для отработки по сути функции — "стрелкИ" (в смысле, "получил команду — выстрелил — забыл"), а отдачу результата возложить уже на другой слой, которому организация на IOCP, poll/kqueue/etc. и прочих событийно-управляемых "по мелочи" движках прописана по определению.

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

N>В Unix мире это реализуется несколькими путями, к которым можно привести классические примеры:


N>1. Отдельно стоящий кэширующий и отдающий процесс-сервер, забирающий данные крупными порциями, обычно сейчас это nginx. У него событийно-управляемое построение и задачу "передать следующую порцию данных" он решает лучше сложного сервера. Дополнительно можно получить от этого несколько вкусностей: сокрытие внутренней сети, лёгкая отдача статического контента.


N>2. Accept filter в ядре (FreeBSD) и аналогичные средства других систем: HTTP accept filter на сокете не выдаёт результат accept() в userland до тех пор, пока не наберётся полный HTTP запрос (есть два варианта фильтра — только по заголовкам или по телу тоже), после чего процесс сервера может получить запрос за один вызов. На специфических задачах вроде того же прокси-фронтэнда ускорение от этого может быть в разы, на "обобщённых на все случаи" серверах вроде Apache — меньше, но тоже заметно.


N>Повторюсь — с использованием таких средств ситуация что "веб-сервер зависит от латентности сети" как-то уходит


N>Краем уха слышал, что в IIS применяются похожие подходы, но не буду давать даже треть зуба за это

Да. Во-первых, в IIS применен драйвер ядра http.sys, который занимается взаимодействием с сокетами. Это позволяет решить несколько проблем — например, позволить нескольким процессам "висеть на 80м порту", разделяясь по URL. Но в основном это, конечно, производительность — предварительный разбор запроса, обработка кэша в режиме ядра, взаимодействие с файловой системой.
Но это всё — прозрачно для веб-приложения. С точки зрения, к примеру, ASP.NET, ядро IIS выступает в роли этакого "локального nginx".

N>В данном случае "не так удобно" может вылиться в колоссальные недостатки, если сравнить необходимость рисования FSM с возможностью линейного написания действий в духе "получил A, передал B, получил ответ, отдал C".

Совершенно верно. Именно в эту сторону сейчас копают ведущие собаководы.

S>>Вот Рихтер придумал библиотечку для .Net, которая даёт улучшенный API к IOCP — по сравнению с ручным программированием коллбэков и протаскиванием состояния.

N>URL? Пределы возможностей?
http://www.wintellect.com/PowerThreading.aspx
Вот его статья про это http://msdn.microsoft.com/en-us/magazine/cc163323.aspx
Ограничений — масса. В основном, конечно, это некрасивость записи по сравнению с линейным написанием. Но всё равно — встроенный в шарп генератор FSM достаточно мощен.
На немерле можно было бы вообще замутить всё еще круче, если только знать, что именно круче. Пока что лично мне неочевидно, какой именно синтаксис тут будет нужен. Мы это кратко обсуждали с Джеффри — я предлагал автоматически заменять в линейном коде блокирующие вызовы на "точки переключения" контекста лёгкого потока. В ответ Рихтер указал на то, что уже сейчас в Power Threading есть возможность указать N запросов для параллельного исполнения, что недостижимо при "обычном" синтаксисе.
Вот как-то так.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[11]: диалог с любителями потоков
От: Sinclair Россия https://github.com/evilguest/
Дата: 09.07.09 04:23
Оценка:
Здравствуйте, gandjustas, Вы писали:
G>В axum есть возможность делать асинхронные вызовы, выглядяще как синхронные и запускать множество таких параллельно.
Вот надо бы поглядеть. Пока руки не доходят.
G>Причем средставми метапрограммирования имхо тоже самое достижимо будет и в nemerle.
Вот-вот. Я лично от немерле ожидаю как раз возможностей обставить шарп именно в быстром применении таких вот штук.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[10]: диалог с любителями потоков
От: Gomes Россия http://irazin.ru
Дата: 09.07.09 05:00
Оценка:
Здравствуйте, Sinclair, Вы писали:

VD>>А меня и уверять не надо. Я и так заню, что подход фиговенький.

S>Ну, я не стану давать тебе советов, но лично я бы сначала ознакомился с предметом. А уже потом делал выводы.

Как прежде люди были просты: они знали только то, чему учились. Ныне, ничему не учась, все знают.

М. Ю. Лермонтов
Re[10]: диалог с любителями потоков
От: VladD2 Российская Империя www.nemerle.org
Дата: 09.07.09 18:43
Оценка:
Здравствуйте, Sinclair, Вы писали:

VD>>Про сокеты речи и не шало. Речь шла о праллельных запросах.

S>Не очень понятно, что такое "запрос" в твоей интерпретации.

Длч HTTP — GET/POST и т.п. А вообще физическое обращение к серверу (не просто открытый сокет).

VD>>И более 10 их окучить не удастся. При этом будет не хилый оверхэд на переключение контекста.

S>А кто тебе сказал, что будут вообще переключения контекста?

Наличие 10 параллельно работающих потоков с одинаковым приоритетом.

VD>>Почитай про эрланг. Для него (хотя язык интерпретатор) и 1000 праллельно работающих задач — это нормально.

S>Ты намекаешь на то, что в эрланге низкая стоимость переключения контекста?

Почти никакая.

S>Потому что получить 1000 параллельно работающих задач на 4х ядрах невозможно — всё равно 996 будут ждать исполнения. Чудес не бывает.


Для клиентов их запросы будут обработаны параллельно. И это главное.
Потоки дороговаты для таких задачей.

VD>>А меня и уверять не надо. Я и так заню, что подход фиговенький.

S>Ну, я не стану давать тебе советов, но лично я бы сначала ознакомился с предметом. А уже потом делал выводы.

Ну, дык ознакомься. Только сразу с двумя. Тогда и поговорим. ОК?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: диалог с любителями потоков
От: Sinclair Россия https://github.com/evilguest/
Дата: 10.07.09 02:51
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Длч HTTP — GET/POST и т.п. А вообще физическое обращение к серверу (не просто открытый сокет).

А что значит "параллельно"? Для меня сеанс GET/POST неразрывно связан с сокетом: он начинается с открытия сокета, и заканчивается (иногда) закрытием.
Мне не очень понятно, можно ли говорить о каком-то запросе, пока нет открытого сокета (или хотя бы ожидающего accept).


VD>Почти никакая.

Я в курсе.

S>>Потому что получить 1000 параллельно работающих задач на 4х ядрах невозможно — всё равно 996 будут ждать исполнения. Чудес не бывает.

VD>Для клиентов их запросы будут обработаны параллельно. И это главное.
Ну конечно же не будут. Чудес не бывает.
VD>Потоки дороговаты для таких задачей.
Совершенно верно. Поэтому никто не применяет 1 поток на 1 клиента. Делают легковесные потоки. В Эрланге это просто реализовано из коробки; остальным приходится прогибаться вручную.
VD>Ну, дык ознакомься. Только сразу с двумя. Тогда и поговорим. ОК?
Продолжаю непонимать, чего именно я не знаю об Эрланге такого, чтоб не мог рассуждать о его производительности применительно к протоколу HTTP.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[12]: диалог с любителями потоков
От: VladD2 Российская Империя www.nemerle.org
Дата: 10.07.09 20:01
Оценка:
Здравствуйте, Sinclair, Вы писали:

G>>Причем средставми метапрограммирования имхо тоже самое достижимо будет и в nemerle.

S>Вот-вот. Я лично от немерле ожидаю как раз возможностей обставить шарп именно в быстром применении таких вот штук.

Дык надо не ожидать, а взять и сделать то что хочется .

В прочем, системные вещи макросам не по зубам. Реализовать легкие потоки/процессы будет весьма затруднительно. Если только, как в yeild-е, переписывать код в конечный автомат. Но и это не просто.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: диалог с любителями потоков
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 11.07.09 08:57
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Собсвтенно к чему я виду. Идея создавать по потоку на запрос — очень сдравая идея. Проблема только в стоимости переключения контекста. Снизить ее и все будет ОК.


Не только в переключении, но и в стоимости самого контекста. Когда на стек даётся 1M, это много, даже если из них используется на каждую нить дай бог 30K, затраты идут на размер виртуальной памяти, на страничный механизм и так далее. Преимущества сред стиля Эрланга ещё и в том, что там можно использовать столько памяти на нить (процесс), сколько реально нужно (ну, максимум в 2 раза за счёт аллокатора кучи). В нагрузочных тестах мы там спокойно рождали и по миллиону процессов, хотя при этом процессорам уже было явно тяжело. На видимых на уровне C тредах в этом случае кончилась бы любая виртуальная память.

VD>По уму в управляемых средах вроде донета и явы можно было бы значительно облегчить стоимость перключения контекста. Особенно это было бы легко сделать если бы эти среды поддерживали бы неизменяемые данные. Тогда можно было бы спокойно создавать 1000 виртуальных потоков или процессов, а всю байду вроде комплейшон потров и другой асинхронности заложить в библиотеки и рантайм.


В принципе не вижу препятствий к тому, чтобы так писать уже сейчас, с небольшой подпоркой в стиле green threads поверх обычных тредов. Но объекты придётся упрощать до данных:)
The God is real, unless declared integer.
Re[13]: диалог с любителями потоков
От: EvilChild Ниоткуда  
Дата: 11.07.09 14:18
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>В прочем, системные вещи макросам не по зубам. Реализовать легкие потоки/процессы будет весьма затруднительно. Если только, как в yeild-е, переписывать код в конечный автомат. Но и это не просто.


Посмотри на Kilim.
Домашняя страница давно лежит почему-то.
Если есть час времени, то можно глянуть видео.
now playing: Heartthrob — Signs
Re[13]: диалог с любителями потоков
От: mrTwister Россия  
Дата: 13.07.09 13:05
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Тут важна сама идея массово-парцелльных вычислений. Дешевые процессы и посылка сообщений.

Главное слово выделено. Особенность HTTP приложений в том, что там время, затрачиваемое на вычисления, ничтожно мало в сравнении с временем, затрачиваемым на IO.
лэт ми спик фром май харт
Re[14]: диалог с любителями потоков
От: VladD2 Российская Империя www.nemerle.org
Дата: 13.07.09 18:50
Оценка:
Здравствуйте, mrTwister, Вы писали:

T>Здравствуйте, VladD2, Вы писали:

VD>>Тут важна сама идея массово-парцелльных вычислений. Дешевые процессы и посылка сообщений.

T>Главное слово выделено. Особенность HTTP приложений в том, что там время, затрачиваемое на вычисления, ничтожно мало в сравнении с временем, затрачиваемым на IO.


А кто сказал что IO там главное и по делу? И кто сказал, что всегда и везде IO занимает основное время?

К тому же что означает IO? Вот я нажимаю на ссылочку "Мой RSDN\Ответы мне" и сайт начинает безбожно тормозить. Это IO виноват? Мне кажется, что IO — это тоже вычисления в массе своей. Пользователю же важно чтобы он по быстрее получил отклик, а не то чем занят процессор сервера. А раз так то нам нужны более пораллельные решения которые обрабатывают данные более интеллектуально. И здесь мне кажется, идея обработки запросов пользователей в легких процессах намного лучше идеи возни с комплешон-портами, пулами потоков и в итоге с массовым переключением контекста потоков.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: диалог с любителями потоков
От: mrTwister Россия  
Дата: 13.07.09 20:09
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А кто сказал что IO там главное и по делу? И кто сказал, что всегда и везде IO занимает основное время?


Опыт профилирования.
Именно поэтому многие высоконагруженные веб-приложения написаны на тормозных скриптовых языках.

VD>К тому же что означает IO? Вот я нажимаю на ссылочку "Мой RSDN\Ответы мне" и сайт начинает безбожно тормозить. Это IO виноват?


Да. Тут имеют место массовые обращения через порты ввода-вывода к БД, распределенному кешу, файловой системе и т.д.

VD>Мне кажется, что IO — это тоже вычисления в массе своей.


Это неважно, что там внутри. Базе данных плевать на то, какого цвета потоки у веб-сервера: зеленые или ещё какие. Ей пришел запрос на IO порт, БД запрос обработала, и выплюнула обратно ответ. Веб сервер всё это время ждал, а не занимался никакими вычислениями.
лэт ми спик фром май харт
Re[16]: диалог с любителями потоков
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.07.09 16:43
Оценка:
Здравствуйте, mrTwister, Вы писали:

VD>>А кто сказал что IO там главное и по делу? И кто сказал, что всегда и везде IO занимает основное время?


T>Опыт профилирования.


Твой? Это уже является показателем?

T>Именно поэтому многие высоконагруженные веб-приложения написаны на тормозных скриптовых языках.


Я таких не знаю. Ну за исключением тех что написаны на Эрланг. Только это как раз совершенно другой случай.

VD>>К тому же что означает IO? Вот я нажимаю на ссылочку "Мой RSDN\Ответы мне" и сайт начинает безбожно тормозить. Это IO виноват?


T>Да. Тут имеют место массовые обращения через порты ввода-вывода к БД, распределенному кешу, файловой системе и т.д.


А СУБД, по-твоему, только к дискам обращается? Данные она не обрабатывает? План построения запросов, соеденения, фильтрацию, кэширование не она делает? На это время не тратится?

VD>>Мне кажется, что IO — это тоже вычисления в массе своей.


T>Это неважно,


Это очень важно! Только это и важно. Если бы все упиралось в медленные устройства ввода-вывода вроде дисков, то твоя позиция имела бы смысл. А так, 99% времени, при обработке веб-запроса, тратится на вычисления. Если бы они работали параллельно и с минимальными затратами, то пользователи были бы удовлетворены. А так пользователь ждет, железо занимается непроизводительными вычислениями, а горе программисты оправдывают эту ситуацию разными глупостями.


T> Базе данных плевать на то, какого цвета потоки у веб-сервера: зеленые или ещё какие. Ей пришел запрос на IO порт, БД запрос обработала, и выплюнула обратно ответ. Веб сервер всё это время ждал, а не занимался никакими вычислениями.


Это махровая чушь. Процессоров в сервере ограниченное количество. Если веб-сервер ждет ответ от СУБД, то процессор занимает СУБД. Это ни разу не ускоряет ни ответ текущему пользователю, ни параллельным.

Если бы веб-сервер и СУБД работали в легких процессах, то при передаче запросов от одного к другому не пришлось бы переключать контекст потока ОС (вызов можно было бы осуществить в рамках того же потока), а сам вызов стоил бы многократно дешевле.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: диалог с любителями потоков
От: VladD2 Российская Империя www.nemerle.org
Дата: 14.07.09 18:21
Оценка:
Здравствуйте, EvilChild, Вы писали:

EC>Я не в курсе как устроен сайт, но есть подозрение, что по нажатию тобой кнопки происходит запрос к серверу БД,

EC>база небось на диске хранится к которому надо сходить, что суть IO.

База, точнее часто используемая ее часть, сидит в памяти (в кэше). Так что обращение к БД в большинстве случае выливается в виртуальный IO, что на самом деле есть вычисления.

EC>Формирование HTTP ответа просто ерунда по сравнению с этим — какие там вычисления то?


Разнообразные. Я их уже перечислял. Превратить строковый запрос в набор данных — это не самая простая задача. И уж точно не IO в ней главное.

EC>Так что львиную долю времени твой запрос проводит в ожидании ответа от диска.


Хрен там. Диски в основном работают только на запись.

EC>Наверняка там есть индексы, ядро держит в кэше куски БД, но это как раз оптимизации цель которых снизить стоимость этого самого IO.


Более верно будет сказать — устранить необходимость в реальном ИО.

Могу сказать за наш сайт. Основное повышение производительности сайта достигалось установкой моря памяти и кучи процессоров. Сейчас на сервере стоит 16 гиг памяти и 8 ядер (два процессора).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: диалог с любителями потоков
От: EvilChild Ниоткуда  
Дата: 14.07.09 18:49
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>База, точнее часто используемая ее часть, сидит в памяти (в кэше). Так что обращение к БД в большинстве случае выливается в виртуальный IO, что на самом деле есть вычисления.

Неужто все только и делают, что смотрят ответы тебе? Объём БД какой? Очень сомнительно, что такие редкоиспользуемые данные будут в кеше, разве, что памяти совсем немерянно. Но ты ближе к телу сайта — тебе виднее, спорить не стану.

EC>>Формирование HTTP ответа просто ерунда по сравнению с этим — какие там вычисления то?


VD>Разнообразные. Я их уже перечислял. Превратить строковый запрос в набор данных — это не самая простая задача. И уж точно не IO в ней главное.


Превратить строковый запрос в набор данных — это отравить текст запроса базе и перелить построчно данные из датаридера в хттп ответ?
С точки зрения кода твоего приложения IO здесь и вправду немного и он относительно дёшев, настоящий IO в БД происходит и сдаётся мне, что он существенно дороже.

EC>>Так что львиную долю времени твой запрос проводит в ожидании ответа от диска.


VD>Хрен там. Диски в основном работают только на запись.


А из БД в память данные как попадают? через астрал?

EC>>Наверняка там есть индексы, ядро держит в кэше куски БД, но это как раз оптимизации цель которых снизить стоимость этого самого IO.


VD>Более верно будет сказать — устранить необходимость в реальном ИО.


VD>Могу сказать за наш сайт. Основное повышение производительности сайта достигалось установкой моря памяти и кучи процессоров. Сейчас на сервере стоит 16 гиг памяти и 8 ядер (два процессора).


Вы одномоментно их ставили или сначало одно, потом другое?
now playing: Dominik Eulberg — Afraid Of Seeing Stars?
Re[17]: диалог с любителями потоков
От: BulatZiganshin  
Дата: 14.07.09 20:39
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Могу сказать за наш сайт. Основное повышение производительности сайта достигалось установкой моря памяти и кучи процессоров. Сейчас на сервере стоит 16 гиг памяти и 8 ядер (два процессора).


кстати, про intel x-25m я надеюсь вы в курсе
Люди, я люблю вас! Будьте бдительны!!!
Re[12]: диалог с любителями потоков
От: BulatZiganshin  
Дата: 14.07.09 20:49
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>>>Потому что получить 1000 параллельно работающих задач на 4х ядрах невозможно — всё равно 996 будут ждать исполнения. Чудес не бывает.

VD>>Для клиентов их запросы будут обработаны параллельно. И это главное.
S>Ну конечно же не будут. Чудес не бывает.
VD>>Потоки дороговаты для таких задачей.
S>Совершенно верно. Поэтому никто не применяет 1 поток на 1 клиента. Делают легковесные потоки. В Эрланге это просто реализовано из коробки; остальным приходится прогибаться вручную.
VD>>Ну, дык ознакомься. Только сразу с двумя. Тогда и поговорим. ОК?
S>Продолжаю непонимать, чего именно я не знаю об Эрланге такого, чтоб не мог рассуждать о его производительности применительно к протоколу HTTP.

вопрос наверно в том, что зелёные потоки должны поддерживаться на уровне вычислительной модели RTS. поскольку нужна синхронизация объектов при попытке одновременного доступа/обновления. что в свою очередь имеет смысл в основном при immutable objects

поэтому 1000 потоков конечно одновременно не работает. вопрос в том, что в отличие от обычных языков программисту удобно программировать (не надо самому заниматься имитацией наличия множества потоков и синхронизация всех мутабельных объектов обходится достаточно дёшево. it just works. а организации пулов потоков и борьбе за синхронизацию мутабельных объектов целые книжки посвящают
Люди, я люблю вас! Будьте бдительны!!!
Re[18]: диалог с любителями потоков
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.07.09 11:53
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

BZ>Здравствуйте, VladD2, Вы писали:


VD>>Могу сказать за наш сайт. Основное повышение производительности сайта достигалось установкой моря памяти и кучи процессоров. Сейчас на сервере стоит 16 гиг памяти и 8 ядер (два процессора).


BZ>кстати, про intel x-25m я надеюсь вы в курсе


Дороговато, мелковато и не весьма не быстро на запись. Вот лет через 5 может быть SSD будут неплохим решением. Но думаю и тогда лишние x гиг и y процессоров будут более выгодным решением.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: диалог с любителями потоков
От: BulatZiganshin  
Дата: 15.07.09 12:39
Оценка:
Здравствуйте, VladD2, Вы писали:

BZ>>кстати, про intel x-25m я надеюсь вы в курсе


VD>Дороговато, мелковато и не весьма не быстро на запись.


а какие у вас объёмы? насчёт скорости записи ты ошибаешься. линейная скорость у домашнего накопителя меньше чем у винтов. iops даже у домашнего раз в 5 выше 15-тысячников
Люди, я люблю вас! Будьте бдительны!!!
Re[20]: диалог с любителями потоков
От: Mr.Cat  
Дата: 15.07.09 12:57
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:
BZ>насчёт скорости записи ты ошибаешься
А скорость записи у ssd все еще деградирует со временем или уже нет?
Re[20]: диалог с любителями потоков
От: VladD2 Российская Империя www.nemerle.org
Дата: 15.07.09 14:20
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

BZ>а какие у вас объёмы?


Последний бэкап был 35 гиг, к сожалению .

BZ>насчёт скорости записи ты ошибаешься. линейная скорость у домашнего накопителя меньше чем у винтов. iops даже у домашнего раз в 5 выше 15-тысячников


iops — это seek?

Сик у SSD конечно неплохой, а вот скорость записи никакая. У нас на одном сервере был RAID 0 из четырех 15-тысячинков, на втором из двух 10-тысячников. В общем-то объем памяти компенсирует скорость винтов с лихвой. Память по любому быстрее любых SSD.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: диалог с любителями потоков
От: BulatZiganshin  
Дата: 15.07.09 15:03
Оценка:
Здравствуйте, Mr.Cat, Вы писали:

BZ>>насчёт скорости записи ты ошибаешься

MC>А скорость записи у ssd все еще деградирует со временем или уже нет?

возможно ты имеешь в виду баг в прошивке intel'овских ssd — его ликвидировали весной, читал на thg. иначе не в курсе
Люди, я люблю вас! Будьте бдительны!!!
Re[22]: диалог с любителями потоков
От: Mr.Cat  
Дата: 16.07.09 08:36
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:
BZ>возможно ты имеешь в виду баг в прошивке intel'овских ssd — его ликвидировали весной, читал на thg. иначе не в курсе
Нет. Проблемы, про которые я читал, были связаны с тем, что минимальный размер стираемого блока на ssd выше, чем минимальный размер записываемого. Поэтому при перезаписи небольшого блока (а со временем любая запись становится перезаписью) нужно сперва считать крупный блок, потом стереть его, потом записать модифицированным. Емнип у ssd хромает как раз random write, что вроде укладывается в вышеописанное.
Re[22]: диалог с любителями потоков
От: BulatZiganshin  
Дата: 16.07.09 09:08
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Ну, и, конечно, надо понимать, что последовательные перезаписи по-любому убивают SSD.


последовательные перезаписи идут в другие физически ячейки. а насчёт trim ты прав
Люди, я люблю вас! Будьте бдительны!!!
Re[23]: диалог с любителями потоков
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.07.09 09:30
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:
BZ>последовательные перезаписи идут в другие физически ячейки. а насчёт trim ты прав
Рано или поздно "другие" ячейки кончаются.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[24]: диалог с любителями потоков
От: Mr.Cat  
Дата: 16.07.09 09:47
Оценка:
Здравствуйте, Sinclair, Вы писали:
Решили путём поддержки операции Trim.
Трим — это хорошо, конечно. Но он разве решает проблему полностью? Что-то мне подсказывает, что при небольшом количестве свободного места на диске все равно какие-нить проблемы да возникнут. Нет?
Re[25]: диалог с любителями потоков
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.07.09 10:04
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:
BZ>если нагрузку размазать равномерно по диску, то получится что-то в районе 100 гб*миллион перезаписей, т.е. на диск за его жизнь можно записать 100 миллионов гигабайт
А, ну да. Для как раз этого и полезна команда trim — иначе контроллер не может выбирать среди свободных страничек и начнёт заниматься членовредительством крайне быстро, задолго до 100 миллионов гигабайт.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[25]: диалог с любителями потоков
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.07.09 10:54
Оценка:
Здравствуйте, Mr.Cat, Вы писали:

MC>Здравствуйте, Sinclair, Вы писали:

MC>Решили путём поддержки операции Trim.
MC>Трим — это хорошо, конечно. Но он разве решает проблему полностью? Что-то мне подсказывает, что при небольшом количестве свободного места на диске все равно какие-нить проблемы да возникнут. Нет?
Нет. С чего? Сейчас проблемы вызваны тем, что контроллер в момент записи блока не знает, какие блоки свободны.
В итоге, он вынужден
1. стирать один из блоков (возможно тот, который только что уже стирался)
2. Делать это синхронно.
При наличии точного списка свободных блоков, контроллер может "играть в пятнадцать":
1. Свободные блоки стираются асинхронно, высвобождая время для операций записи
2. У контроллера при записи есть выбор любого из свободных блоков; в итоге есть возможность поддержки списка LRU и максимизации периода ротации каждой страницы.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[26]: диалог с любителями потоков
От: BulatZiganshin  
Дата: 16.07.09 10:56
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>В итоге, он вынужден

S>1. стирать один из блоков (возможно тот, который только что уже стирался)
S>2. Делать это синхронно.

синхронно — нет, есть кеш на RAM
Люди, я люблю вас! Будьте бдительны!!!
Re[26]: диалог с любителями потоков
От: BulatZiganshin  
Дата: 16.07.09 10:57
Оценка:
Здравствуйте, Sinclair, Вы писали:

BZ>>если нагрузку размазать равномерно по диску, то получится что-то в районе 100 гб*миллион перезаписей, т.е. на диск за его жизнь можно записать 100 миллионов гигабайт

S>А, ну да. Для как раз этого и полезна команда trim — иначе контроллер не может выбирать среди свободных страничек и начнёт заниматься членовредительством крайне быстро, задолго до 100 миллионов гигабайт.

нет, просто делается маппинг адресов
Люди, я люблю вас! Будьте бдительны!!!
Re[22]: диалог с любителями потоков
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.07.09 11:05
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

VD>>Сик у SSD конечно неплохой, а вот скорость записи никакая.


BZ>да, ты видимо просто не читал про intel ssd. они в разы опережают то, про что ты читал


Я то как раз читал. Скорость записи у указанной модели ниже чем у 7-тысячников.
Сам лучше почитай. У intel x-25m скорость записи где-то 70 мег в секунду. У нас сейчас где-тр более 300.
Учитывая, что основная часть БД лежит в паяти тольку от SSD не будте никакого. Только выброс денег.
Плюсь это игрушки для новаторов. Никто не гарантирует, что SSD заработают с контрллером что встроен в мать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: диалог с любителями потоков
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.07.09 11:25
Оценка:
Здравствуйте, mrTwister, Вы писали:

T>>>Опыт профилирования.

VD>>Твой? Это уже является показателем?
T>Разумеется. "Практика — критерий истины" (с)

У каждого практика своя. И истина тоже. Так что не надо свой личный опыт воспринимать как критерий истины в последней инстанции.

T>>>Именно поэтому многие высоконагруженные веб-приложения написаны на тормозных скриптовых языках.

VD>>Я таких не знаю. Ну за исключением тех что написаны на Эрланг. Только это как раз совершенно другой случай.
T>Ну вот, например, эти были написаны на PHP: Facebook, Wikipedia (MediaWiki), Yahoo!, WordPress, YouTube, MyYearbook, Digg, Joomla, Tagged.

Это мягко говоря не правда. Выскогонагруженными в том же Wikipedia является поиск. Который раньше был написан на Моно, а потом из соображений быстродействия был переписан на Яве. Текстовая часть вики живет на кэше. Так что действительно хватит и скриптов. В Yahoo тоже движок поиска написан на С++. В Яндексе и гугле, как я понимаю та же картина. В YouTube основная нагрузка — это потокове видио. Стримы тоже не скриптами отдаются. Так что не надо.

В прочем проблема масштабируемости решается и при низком быстродействии. Можно поставить 100 серверов вместо 10 и проблема будет решена. Для многих проще вложиться в железо, чем заниматься разработкой софта. Программист, ведь, стоит столько же в месяц как несколько серверов. Присчем серверы будут работать и работать потребляя только электричества, а программисту нужно платить каждый месяц.

T>>>Да. Тут имеют место массовые обращения через порты ввода-вывода к БД, распределенному кешу, файловой системе и т.д.

VD>>А СУБД, по-твоему, только к дискам обращается? Данные она не обрабатывает? План построения запросов, соеденения, фильтрацию, кэширование не она делает? На это время не тратится?

T>Клиенту СУБД (то есть Web-серверу в нашем случае) совершенно плевать, что там делается внутри СУБД.


Клиент СБДУ плевать. Он же программа, а вот клиенту обращающемуся с запросом не плевать, так как он человек. И ему важно, чтобы отклик был как можно быстрее.

T>Клиент общается с базой через порты ввода-вывода (сеть, трубы).


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

T>В этом смысле, для него любое обращение к базе — это стандартная IO операция, которая отлично ложится на IOCP.


Это все проблемы вызванные современной архитектурой компьютеров, а не достижение человечества. Была бы многозадачность дешевле, а процессы легче про такую глупость как порты ввода вывода никто даже не вспоминал бы.

Кстати, когда СУБД стоит на той же машине, что и клиент (скажем веб-сервер) выгоднее использовать не пайпы или сокеты, а прямой доступ к памяти (если СУБД позволяет).

Собственно наш опыт показывает, что вынос СУБД на отдельный компьютер резко ускоряет работу системы. Это говорит, о том, что вычислительные затраты — это главное.

VD>>>>Мне кажется, что IO — это тоже вычисления в массе своей.

T>>>Это неважно,

VD>>Это очень важно! Только это и важно. Если бы все упиралось в медленные устройства ввода-вывода вроде дисков, то твоя позиция имела бы смысл. А так, 99% времени, при обработке веб-запроса, тратится на вычисления. Если бы они работали параллельно и с минимальными затратами, то пользователи были бы удовлетворены. А так пользователь ждет, железо занимается непроизводительными вычислениями, а горе программисты оправдывают эту ситуацию разными глупостями.

T>Вычислениями занимается не Web-сервер (о котором идет речь в этой ветке) а СУБД.

Клиенту это монопенисуально. Ему важен отклик. Никакие порты завершения и т.п. не в силах ускорить работу системы если все упирается в вычислительные ресурсы. Нужно ставить больше процессоров или делать многозадачность дешевле. Майкросовф на сегодня идет экстенсивным путем. В прочем Сингулярити — это движение в правильном направлении. И есть некоторый шанс, что ее идеи таки воплотят в коммерческом продукте.

T>Чтобы Web-сервер по сети обращался к СУБД, которая находится на другой машине и при этом выполнение запроса бы происходило в одном процессе и потоке с Web-сервером — это круто!!!


Если машины разные, то вопросов нет. Но если это не та, то какой смысл заниматься хернеЙ?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[27]: диалог с любителями потоков
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.07.09 11:35
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:
BZ>нет, просто делается маппинг адресов
Без трима ничего интересного из маппинга адресов ты не получишь. Очень быстро чистые страницы кончатся; придется перезаписывать уже перезаписанные. Иначе зачем ты думаешь вендоры "скрывают" часть ёмкости SSD дисков?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[27]: диалог с любителями потоков
От: Sinclair Россия https://github.com/evilguest/
Дата: 16.07.09 11:35
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:
BZ>синхронно — нет, есть кеш на RAM
Тем не менее именно из-за этого происходит деградация скорости записи. Сначала свободных страниц хватает; затем рано или поздно они кончаются, и запись каждой страницы ведёт к предварительному стиранию блока.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[23]: диалог с любителями потоков
От: BulatZiganshin  
Дата: 16.07.09 12:50
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>>>Сик у SSD конечно неплохой, а вот скорость записи никакая.


BZ>>да, ты видимо просто не читал про intel ssd. они в разы опережают то, про что ты читал


VD>Я то как раз читал. Скорость записи у указанной модели ниже чем у 7-тысячников.


1. скорость чистой записи тебе не нужна, смотри iops
2. у серверной модели она больше 200 мб/с, отя цимес всё равно не в этом

VD>Сам лучше почитай. У intel x-25m скорость записи где-то 70 мег в секунду. У нас сейчас где-тр более 300.

VD>Учитывая, что основная часть БД лежит в паяти тольку от SSD не будте никакого. Только выброс денег.
VD>Плюсь это игрушки для новаторов. Никто не гарантирует, что SSD заработают с контрллером что встроен в мать.

память не компенсирует большого числа операций записи
Люди, я люблю вас! Будьте бдительны!!!
Re[28]: диалог с любителями потоков
От: BulatZiganshin  
Дата: 16.07.09 12:52
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, BulatZiganshin, Вы писали:

BZ>>нет, просто делается маппинг адресов
S>Без трима ничего интересного из маппинга адресов ты не получишь. Очень быстро чистые страницы кончатся; придется перезаписывать уже перезаписанные. Иначе зачем ты думаешь вендоры "скрывают" часть ёмкости SSD дисков?

ещё раз. ресурс устройства — 10^17 байт, к примеру. при операции записи данные заносятся в наименее изношенный блок памяти, а из него переносятся в другой
Люди, я люблю вас! Будьте бдительны!!!
Re[28]: диалог с любителями потоков
От: BulatZiganshin  
Дата: 16.07.09 12:54
Оценка:
Здравствуйте, Sinclair, Вы писали:

BZ>>синхронно — нет, есть кеш на RAM

S>Тем не менее именно из-за этого происходит деградация скорости записи. Сначала свободных страниц хватает; затем рано или поздно они кончаются, и запись каждой страницы ведёт к предварительному стиранию блока.

это не *обязательно* делать синхронно
Люди, я люблю вас! Будьте бдительны!!!
Re[23]: диалог с любителями потоков
От: Слоноежик  
Дата: 16.07.09 13:06
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Плюсь это игрушки для новаторов. Никто не гарантирует, что SSD заработают с контрллером что встроен в мать.


А почему бы им не заработать. Так себе обыкновенное блоковое устройтво.
для забивания гвоздя надо выбирать правильный микроскоп.
Re[24]: диалог с любителями потоков
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.07.09 13:21
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

BZ>1. скорость чистой записи тебе не нужна, смотри iops


Мне в основном она и важна. У нас логи БД на диск пишутся... постранично.

BZ>2. у серверной модели она больше 200 мб/с, отя цимес всё равно не в этом


Я уже сказал что у нас на не самом быстром варианте под 300?
Указан был десктопный. Причем вы вообще разговариваете про игрушки. Их в москве днем с огнем не съищешь

VD>>Сам лучше почитай. У intel x-25m скорость записи где-то 70 мег в секунду. У нас сейчас где-тр более 300.

VD>>Учитывая, что основная часть БД лежит в паяти тольку от SSD не будте никакого. Только выброс денег.
VD>>Плюсь это игрушки для новаторов. Никто не гарантирует, что SSD заработают с контрллером что встроен в мать.

BZ>память не компенсирует большого числа операций записи


"Большого" — это хороший термин. Ну, считай у нас не большое количество. У нас много посетителей не все из которых пишут.
Так как пишутся в основном логи SQL-сервера, то важна скорость записи, а не сик. Она у SSD в расчете на доллар весьма посредственная.

В общем, мне надоело спорить с читателями теоретиками. Заведете себе сервер с большим количеством посетителей, поэкспериментируйте... Потом расскажете нам результат. А мы пока что как-нибудь по старинке.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[18]: диалог с любителями потоков
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.07.09 13:34
Оценка:
Здравствуйте, EvilChild, Вы писали:

EC>Неужто все только и делают, что смотрят ответы тебе? Объём БД какой? Очень сомнительно, что такие редкоиспользуемые данные будут в кеше, разве, что памяти совсем немерянно. Но ты ближе к телу сайта — тебе виднее, спорить не стану.


Ага. Виднее. И давайте как вы поверите мне на слово, что лишние 8 гиг оперативки и 4 проца с большей частотой дали выигрыш в производительности намного больший чем замена страйпа на двух 10-тысячниках (которые к слову сейчас снова трудятся) на страйп на 4-ех 15-тысячинках.

EC>Превратить строковый запрос в набор данных — это отравить текст запроса базе и перелить построчно данные из датаридера в хттп ответ?


Нет.

EC>С точки зрения кода твоего приложения IO здесь и вправду немного и он относительно дёшев, настоящий IO в БД происходит и сдаётся мне, что он существенно дороже.


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

EC>А из БД в память данные как попадают? через астрал?


Они туда редко попадают. Намного реже чем SQL-сервер их отдает.

EC>Вы одномоментно их ставили или сначало одно, потом другое?


Мы серверы апгрэйдили и сбирали. Сначала был Celeron 1.3 Ггц, гиг памяти и идешный винт. Потом 2 P4 и 4 гига, потом 4 Амд и 8 гиг (+ 64-битная ОС). Сейчас 8 Core 2 и 16 гиг.

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

Лучший результат был только когда распределяли нагрузку между двумя серверами. Но это решение получается менее надежным и более сложным в поддержке. К тому же второй сервер сломался и не хватает времени и денег чтобы его восстановить.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[24]: диалог с любителями потоков
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.07.09 14:01
Оценка:
Здравствуйте, Слоноежик, Вы писали:

VD>>Плюсь это игрушки для новаторов. Никто не гарантирует, что SSD заработают с контрллером что встроен в мать.


С>А почему бы им не заработать. Так себе обыкновенное блоковое устройтво.


Ты на своем веку сколько новых технологий опробовал? Я достаточно. Очень редко было так, чтобы новая технология сразу же замечательно стыковалась с оборудовонием которое было разработано до него.

Вот тебе первый обзор по куазанному винту:
http://www.ixbt.com/storage/ssd-intel-x25m.shtml
Читай внимательно там как раз сказано, что есть проблемы совместимости с контроллерами.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: диалог с любителями потоков
От: EvilChild Ниоткуда  
Дата: 16.07.09 15:36
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Ага. Виднее. И давайте как вы поверите мне на слово, что лишние 8 гиг оперативки и 4 проца с большей частотой дали выигрыш в производительности намного больший чем замена страйпа на двух 10-тысячниках (которые к слову сейчас снова трудятся) на страйп на 4-ех 15-тысячинках.

Это согласие или возражение? Я именно это и говорил, что кэширование помогает снизить стоимость IO.

EC>>С точки зрения кода твоего приложения IO здесь и вправду немного и он относительно дёшев, настоящий IO в БД происходит и сдаётся мне, что он существенно дороже.


VD>Клиенту по барабану как запрос обрабатывается. Ему важно за сколько времени ему приходит ответ.

Замечательно. Начали с потоков и IO, а скатились к клиентам. Ты бы ещё разрешение экрана у пользователя сюда привёл.

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

Думаю корректнее будет сказать пропускная способность выше.

VD>Лучший результат был только когда распределяли нагрузку между двумя серверами. Но это решение получается менее надежным и более сложным в поддержке. К тому же второй сервер сломался и не хватает времени и денег чтобы его восстановить.

2 сервера это один с БД, второй — с веб?
now playing: Extrawelt — Trummerfeld (Oliver Huntemann Remix)
Re[25]: диалог с любителями потоков
От: Слоноежик  
Дата: 16.07.09 15:51
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Ты на своем веку сколько новых технологий опробовал? Я достаточно. Очень редко было так, чтобы новая технология сразу же замечательно стыковалась с оборудовонием которое было разработано до него.

Глупо сравнивать технологию которую обкатывали минимум 20 лет с технологией которая появилась вышла пару лет назад. Да и то даже сейчас с прошивкой винчестеров косяки случаются.

VD>Вот тебе первый обзор по куазанному винту:

VD>http://www.ixbt.com/storage/ssd-intel-x25m.shtml
VD>Читай внимательно там как раз сказано, что есть проблемы совместимости с контроллерами.

Никаких проблем — глупо требовать от дешёвой SSD-шки для нетбука полной поддержки переупорядочения комманд.
А в нормальных SSD-шках есть кэш память правда она используется не только для переупорядочения (тут вообще аппаратная часть гораздо более продвинутая).
для забивания гвоздя надо выбирать правильный микроскоп.
Re[20]: диалог с любителями потоков
От: VladD2 Российская Империя www.nemerle.org
Дата: 16.07.09 16:57
Оценка:
Здравствуйте, EvilChild, Вы писали:

Ты прочити всю тему целиком и по ходу ее формирования. А то у меня ощущение, что ты влез с этого мест.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[30]: диалог с любителями потоков
От: yuriylsh  
Дата: 18.07.09 02:52
Оценка:
Y>В SSD диске нет доступа к отдельной ячейке (байту). Ячейки организованы в страницу (4Кб). Страницы, в свою очередь, организованы в блок из 128 страниц – 512Кб. Давай представим, что мы записали файл размером в 32 страницы (128Кб) в блок. Затем еще один файл размером 64 страницы. Дальше мы удалили первый файл – так как команды удаления для диска нету, то ОС помечает у себя что первые 32 страницы блока свободны и на этом все с удалением (диск вообще в радостном неведении об этом событии, поэтому, все что происходит дальше, ему приходиться делать синхронно). Итого у нас 32 страницы в начале блока свободны, причем об этом знает только ОС (пометим эти страницы как С) – но не чисты (Ч), 64 заняты (З) и 64 страницы в конце чисты: блок выглядит так — СЗЗЧЧ.

Что-то я зарапортовался Представим, что блок — 160 страниц
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Re[30]: диалог с любителями потоков
От: zlonovich  
Дата: 20.07.09 20:57
Оценка:
Здравствуйте, yuriylsh, Вы писали:

Y>Здравствуйте, BulatZiganshin, Вы писали:


BZ>>Здравствуйте, Sinclair, Вы писали:


BZ>>>>синхронно — нет, есть кеш на RAM

S>>>Тем не менее именно из-за этого происходит деградация скорости записи. Сначала свободных страниц хватает; затем рано или поздно они кончаются, и запись каждой страницы ведёт к предварительному стиранию блока.

BZ>>это не *обязательно* делать синхронно


Y>В том-то и дело, что обязательно. Проблема в том, что диск понятия не имеет что какая-то страница была удалена. Операционка не посылает команды удаления (TRIM) диску ибо ее чего? — правильно, нету. Диск узнает что у него проблемы в тот момент, когда ему приходит команда на перезапись, и соответсвенно, решает ее (вот где тормоза) только в этот момент – тобишь, синхронно. Попробую обяснить.

Y>В SSD диске нет доступа к отдельной ячейке (байту). Ячейки организованы в страницу (4Кб). Страницы, в свою очередь, организованы в блок из 128 страниц – 512Кб. Давай представим, что мы записали файл размером в 32 страницы (128Кб) в блок. Затем еще один файл размером 64 страницы.
Диск — блоковое устройтво, и адресация у него идет ессно секторами по 512 байт. И пишем мы соответственно по некаторому LBA (да да именно он) некаторое количество секторов. Да и если посмотреть то запись одного файла это как минимум 2 записи по 2-м разным LBA разного кол-ва секторов, файловые системы никто не отменял.
Y> Дальше мы удалили первый файл – так как команды удаления для диска нету, то ОС помечает у себя что первые 32 страницы блока свободны
Собственно это удаление с точки зрения накопителя это тоже есть просто запись.
Y> Вот тут у SSD диска проблема – писать в свободные страницы он не умеет, только в чистые, тобишь, ему С + ЧЧ надо превратить в Ч+ЧЧ, тобишь, стиреть первые 32 страницы.
Значит нам нужно целых пол-мегабайта только для для того чтобы обновить кусок данных. Подобное можно предположить про SSD так как там есть буфер для того чтобы считать эти данные (если конечно забыть про прозводительность вообще) так как например некаторые флэш микрухи имеют время записи одного блока порядка полутора секунд. Собственно при таком подходе простые флэшки вообще не могут работать. Трудно прочитать в память содержимое блока если памяти под буфера всего 48К.

[остальное поскипнуто]

Думаю тут стоит избавится от парочки мифов которые возникали в этом типике:

1) Контроллеры для флэшек да и SSD имеют достаточно сложные прошивки которые умеют делать много чего: следить за равномерным износом блоков и перемещать данные из более изношенных блоков в менее изношенные, cледить за состоянием уровня заряда в яйчейках флэш-памяти так как он теряется во время чтения и переносить данные когда он становится низким (естественно это все смотрится по косвенным признакам), обрабатывать ошибки и восстанавливать данные в случае если произошел сбой питания(флӕш память не любит если изчезает питание во время записи) или ошибка записи.
2) Учитывая что есть возможность только записать(а точнее только переключать 1-ки в 0-ки) данные каждый раз пишутся в новое место (включая и контрольные структуры) 2 записи по одному и тому же LBA в общем случае физически после записи будут находится в разных местах на флэш памяти.
3) Давно не слышал про просто SLC и просто MLC память. Дорого это иметь отдельную микруху для каждого типа памяти. А про память которая может работать в SLC режиме и MLC режиме причэм для каждого блока можно выбирать в каком режиме он будет работать слышал.
4) Учитывая что данные перезаписать невозможно без стирания всего блока то последовательные длинные записи гораздо проще реализуются чем короткие рандомные. Cобственно в SSD буферная память и используется для того чтобы уменьшить влияние случайных записей и собственно попытаться уменьшить само кол-во записей. Возьмем предидущий пример: после прихода первого файла контроллер может решить вообще оставить его в памяти и ничего не писать, а когда придет второй кусок записать сразу весь второй файл в 96 страниц.
5) В принципе основные команды это чтение нескольких сектров и запись нескольких секторов. Про стирание слышал только в контексте SD карточек.

З.Ы. Пора заканчивать этот флуд про флэшки или выделять эту ветку в отдельную тему

З.З.Ы. На флэшки и на SSD-шкам(но в гораздо меньшей мере) смотреть со стороны фирмваря приходилось.
Re[31]: диалог с любителями потоков
От: yuriylsh  
Дата: 20.07.09 22:37
Оценка:
Здравствуйте, zlonovich, Вы писали:
Y>> Дальше мы удалили первый файл – так как команды удаления для диска нету, то ОС помечает у себя что первые 32 страницы блока свободны
Z>Собственно это удаление с точки зрения накопителя это тоже есть просто запись.

Угу, так вот проблема в том, что этой команды записи (TRIM — логически это удаление, физически — запись) пока и нету, о чем и речь ведеться.

Y>> Вот тут у SSD диска проблема – писать в свободные страницы он не умеет, только в чистые, тобишь, ему С + ЧЧ надо превратить в Ч+ЧЧ, тобишь, стиреть первые 32 страницы.

Z>Значит нам нужно целых пол-мегабайта только для для того чтобы обновить кусок данных. Подобное можно предположить про SSD так как там есть буфер для того чтобы считать эти данные (если конечно забыть про прозводительность вообще) так как например некаторые флэш микрухи имеют время записи одного блока порядка полутора секунд. Собственно при таком подходе простые флэшки вообще не могут работать. Трудно прочитать в память содержимое блока если памяти под буфера всего 48К.

Согласен, вот только SSD это не простая флэшка, ты же сам дальше об этом говоришь.

Z>[остальное поскипнуто]


Z>Думаю тут стоит избавится от парочки мифов которые возникали в этом типике:


Z>1) Контроллеры для флэшек да и SSD имеют достаточно сложные прошивки которые умеют делать много чего: следить за равномерным износом блоков и перемещать данные из более изношенных блоков в менее изношенные, cледить за состоянием уровня заряда в яйчейках флэш-памяти так как он теряется во время чтения и переносить данные когда он становится низким (естественно это все смотрится по косвенным признакам), обрабатывать ошибки и восстанавливать данные в случае если произошел сбой питания(флӕш память не любит если изчезает питание во время записи) или ошибка записи.

Z>2) Учитывая что есть возможность только записать(а точнее только переключать 1-ки в 0-ки) данные каждый раз пишутся в новое место (включая и контрольные структуры) 2 записи по одному и тому же LBA в общем случае физически после записи будут находится в разных местах на флэш памяти.
Z>3) Давно не слышал про просто SLC и просто MLC память. Дорого это иметь отдельную микруху для каждого типа памяти. А про память которая может работать в SLC режиме и MLC режиме причэм для каждого блока можно выбирать в каком режиме он будет работать слышал.
Z>4) Учитывая что данные перезаписать невозможно без стирания всего блока то последовательные длинные записи гораздо проще реализуются чем короткие рандомные. Cобственно в SSD буферная память и используется для того чтобы уменьшить влияние случайных записей и собственно попытаться уменьшить само кол-во записей. Возьмем предидущий пример: после прихода первого файла контроллер может решить вообще оставить его в памяти и ничего не писать, а когда придет второй кусок записать сразу весь второй файл в 96 страниц.
Z>5) В принципе основные команды это чтение нескольких сектров и запись нескольких секторов. Про стирание слышал только в контексте SD карточек.

Да это все оптимизации для продления жизни (с этим уже сейчас у SSD все не так уж плохо) и попытки избавиться от проблем с записью на несвежий диск — вот тут без TRIM тяжко, проблема не решается, а откладывается. В зависимости от паттерна использования диска (ну и объема, конечно же) ты очень долго можешь не видеть деградации, но рано или поздно ты к ней придешь.
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Re[32]: диалог с любителями потоков
От: zlonovich  
Дата: 20.07.09 23:18
Оценка:
Здравствуйте, yuriylsh, Вы писали:

Y>Да это все оптимизации для продления жизни (с этим уже сейчас у SSD все не так уж плохо) и попытки избавиться от проблем с записью на несвежий диск — вот тут без TRIM тяжко, проблема не решается, а откладывается. В зависимости от паттерна использования диска (ну и объема, конечно же) ты очень долго можешь не видеть деградации, но рано или поздно ты к ней придешь.

Запись на несвежий диск — это собственно и есть стандартный вид записи и стандартный режим работы флэш накопителя, и трим конечно мог бы помочь тут а может и помешать ведь эту информацию надо где-то хранить и дополнительно обрабатывать. А с деградацией все равно ничего не сделать Трим ее может только ненадолго отсрочить. А вот платить за трим полной потерей совместимости при этом придется.
е
Re[33]: диалог с любителями потоков
От: yuriylsh  
Дата: 21.07.09 02:04
Оценка:
Здравствуйте, zlonovich, Вы писали:

Z>Запись на несвежий диск — это собственно и есть стандартный вид записи и стандартный режим работы флэш накопителя, и трим конечно мог бы помочь тут а может и помешать ведь эту информацию надо где-то хранить и дополнительно обрабатывать.


Не понял, каку информацию? TRIM — это всего лишь возомжность произвести перезапись блока при удалении (или отложенно, после удаления, например, как дефрагментацию ты можешь делать отложенно, или по расписанию), а не во время записи данных в непочищенный блок. Какую информацию ты имеешь в виду?

Z>А с деградацией все равно ничего не сделать Трим ее может только ненадолго отсрочить.


Не, это без TRIM така ситуация. Это комманда призвана ее разрешить.

Z>А вот платить за трим полной потерей совместимости при этом придется.


С чего ты взял? Если диск не поддерживает TRIM, то он просто будет функционировать как текущие диски.
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Re[31]: диалог с любителями потоков
От: netch80 Украина http://netch80.dreamwidth.org/
Дата: 21.07.09 08:25
Оценка:
Здравствуйте, zlonovich, Вы писали:

Y>>В SSD диске нет доступа к отдельной ячейке (байту). Ячейки организованы в страницу (4Кб). Страницы, в свою очередь, организованы в блок из 128 страниц – 512Кб. Давай представим, что мы записали файл размером в 32 страницы (128Кб) в блок. Затем еще один файл размером 64 страницы.

Z>Диск — блоковое устройтво, и адресация у него идет ессно секторами по 512 байт. И пишем мы соответственно по некаторому LBA (да да именно он)

Тогда уж расшифровали бы — "linear block address". А то "он", "он" — скорее можно подумать, что речь про C2H5OH.

Далее, диск-то блоковый, но над ним FS, у которой свои соображения о том, что есть блок и почему.

Z> некаторое количество секторов. Да и если посмотреть то запись одного файла это как минимум 2 записи по 2-м разным LBA разного кол-ва секторов, файловые системы никто не отменял.

Y>> Дальше мы удалили первый файл – так как команды удаления для диска нету, то ОС помечает у себя что первые 32 страницы блока свободны
Z>Собственно это удаление с точки зрения накопителя это тоже есть просто запись.

Вы с прямым углом путаете. Запись _метаданных_ на диск о том, что какие-то страницы свободны, никак не подсказывает диску, какие области данных (в Ваших терминах — блоки с каким конкретно LBA) стали свободны: он ничего не знает про используемую FS. Чтобы диск начал оптимизировать, ему надо _явно_ сказать "вот то что тут — уже неважно".

Z>Думаю тут стоит избавится от парочки мифов которые возникали в этом типике:


Z>1) Контроллеры для флэшек да и SSD имеют достаточно сложные прошивки которые умеют делать много чего: следить за равномерным износом блоков и перемещать данные из более изношенных блоков в менее изношенные, cледить за состоянием уровня заряда в яйчейках флэш-памяти так как он теряется во время чтения и переносить данные когда он становится низким (естественно это все смотрится по косвенным признакам), обрабатывать ошибки и восстанавливать данные в случае если произошел сбой питания(флӕш память не любит если изчезает питание во время записи) или ошибка записи.


А что, не умеют ничего из перечисленного? Или умеют только часть? Если Вы уж решили "избавить от мифов", надо говорить конкретнее: что именно миф, для какого типа/поколения.
Или это Вы, наоборот, утверждаете, а не отрицаете? Тогда хорошо было бы, чтобы Вы выражались яснее, а то телепать каждый раз очень тяжело...

Z>5) В принципе основные команды это чтение нескольких сектров и запись нескольких секторов. Про стирание слышал только в контексте SD карточек.


Ну вот, как видите, времена изменились.

Z>З.Ы. Пора заканчивать этот флуд про флэшки или выделять эту ветку в отдельную тему


Z>З.З.Ы. На флэшки и на SSD-шкам(но в гораздо меньшей мере) смотреть со стороны фирмваря приходилось.


Ну тогда расскажите подробнее. Лучше со слайдами:))
The God is real, unless declared integer.
Re[22]: диалог с любителями потоков
От: VGn Россия http://vassilsanych.livejournal.com
Дата: 27.07.09 13:57
Оценка:
BZ>80 гиг домашней серии стоят $1000,
Я позавчера видел в продаже 120 за $400, если мы о стоимости SSD
Всё-равно дорого, но ИМХО с такими темпами через год-полтора у производителей HDD уже будут проблемы.
... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
Re[26]: диалог с любителями потоков
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.07.09 15:50
Оценка:
Здравствуйте, Слоноежик, Вы писали:

С>Глупо сравнивать технологию которую обкатывали минимум 20 лет с технологией которая появилась вышла пару лет назад. Да и то даже сейчас с прошивкой винчестеров косяки случаются.


Глупо думать, что есть разные времена.

VD>>Вот тебе первый обзор по куазанному винту:

VD>>http://www.ixbt.com/storage/ssd-intel-x25m.shtml
VD>>Читай внимательно там как раз сказано, что есть проблемы совместимости с контроллерами.

С>Никаких проблем — глупо требовать от дешёвой SSD-шки для нетбука полной поддержки переупорядочения комманд.

С>А в нормальных SSD-шках есть кэш память правда она используется не только для переупорядочения (тут вообще аппаратная часть гораздо более продвинутая).

Дешевые это те что за 1000 баксов? А в дорогих говоришь кэш есть? Ну, так за эту 1000 баксов можно столько памяти купить...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[28]: диалог с любителями потоков
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.07.09 13:31
Оценка:
Здравствуйте, Слоноежик, Вы писали:

VD>>Дешевые это те что за 1000 баксов? А в дорогих говоришь кэш есть? Ну, так за эту 1000 баксов можно столько памяти купить...

С>Дешёвые это которые гуглятся по словамnetbook ssd

Это бред. Ты его сам читай. Только смотри чтобы мозг не снесло ненароком.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.