Этот процесс называется сублимация, и он идёт менее активно, чем испарение воды. Процесс зависит от парциального давления паров воды в атмосфере.
С барокамерой мимо. Как показывает график фазовых состояний воды, при низких давлениях и температуре ниже ноля в жидком виде вода находиться не может. Более того, можете сами провести опыт: поставить в камеру миску с водой и откачать воздух — вода очень быстро превратится в лёд.
Курсовые не считаются, обычно их защита проходит в узком кругу на кафедре. А вот выступления с защитой серьёзной работы или с докладом о продукте, который долго разрабатывали командой, да ещё и для требовательной (типа доклада на конференции) — это опыт другого рода, и далеко не у каждого студента он есть. Есть небольшая разница между выступлениями с курсовой пред своими преподами и своей группой, и дипломом, когда приходят всякие умные дядьки и вообще если накосячишь — то запорешь себе диплом. И выступление перед залом в несколько сотен человек о штуке, которую твоя команда делала не один месяц, сравнимо с дипломом по волнительности.
Ага, туда. ОО, если вводить с модификатором @fields.request: и звёздочками — то работает! Не очень очевидно, но сойдёт. И со слешами какая-то беда. Надо будет попробовать залить в него мноооого логов.
Скопировал урл из первой строки лога, ввёл в поисковую строчку, ничего не нашлось :(
Вы не в курсе, можно ли запилить это так, чтобы люцен проиндексировал содержимое строчки лога? Масштабироваться, на сколько я знаю, он должен действительно неплохо.
Да, вы уже сделали пару необоснованных заявлений, типа «readahead плохо, потому что MongoDB с ним работает плохо» и «Windows не скидывает страницы на диск, в итоге Allocated стремится к нулю после записи больших файлов».
Специально сейчас на Win7 скопировал с сетевой шары на локальный диск 400мб файл, ближе к концу копирования действительно было мало Allocated памяти, но через минуту после копирования Allocated = Cached + Free, то есть грязных страниц не осталось. Все ссылки, что вы привели — про то, что File Cache занимает весь доступный объём ОЗУ и приложениям, которые предварительно резервировали себе память, ничего не достаётся и они даже в файл подкачки вытесняются. Ну так это же нормально, оно так и должно работать! Файловый кэш выедает всю свободную память, чтобы она не простаивала, для ускорения операции записи. Если не нравится — уменьшайте объём памяти, который готовы выделять под буферы, делайте синк на диск чаще, инструменты то есть для этого.
Вы готовы привести другие ссылки, где будет написано про большое количество грязных страниц в памяти после окончания процесса копирования? Или, может быть, готовы показать ссылку, где будет описано, что страницы не сбрасываются на диск, когда вызывается sync? Мне такие не попадались.
По вашим ответам складывается ощущение, что вы считаете себя большим специалистом в области программирования, но при этом плохо понимаете, как работает файловых кэш. Вы много раз повторили про случайный доступ к диску, про монго, но ни разу не описали структуры данных, к которым тот самый случайный доступ производится. Вы опять же голосновно объявили cfq «десктопным» шедулером, хотя только он, в текущий момент, поддерживает io приоритеты.
Можете не отвечать, но советую всё же разобраться с «магией», которую применяют во всех современных операционных системах много лет, и с которой успешно работают миллионы программистов по всему миру. Расширьте кругозор. И не стоит учиться этому у разработчиков MongoDB, это далеко не самая лучшая база данных.
У вас в описании задачи про китайские шашки не написано, чего получить то надо:) По тексту статьи понял, что должна остаться только 1 фишка, правильно?
Вы же сами не далее как вчера писали, что не использовать реид из ссд карт крайне плохо из-за возможности умирания контроллера SSD. Или предполагаете, что LSI контроллер существенно надёжней?
Как хранит данные MongoDB, можно почитать в интернетах.
Это переводится как «я не знаю»?
О том, что RA вредит случайному доступу, очевидно и ребёнку, о том, что RA не помогает, я вам написал несколько раз — при линейном чтении от RA никакого толка, потому что линейно всегда читается большими блоками.
You can always use POSIX_FADVISE_RANDOM to disable it, but it's seldom
something that people do. And there are real loads that have random
components to them without being _entirely_ random, so in an optimal world
we should just have heuristics that work well.
sendfile, кстати, через readahead работает. Примеры, когда readahead будет хорошо работать: вычитывание b-tree индекса, подгрузка какой нибудь игрой ресурсов из большого ресурсного файла. В обоих случаях доступ рандомный, да не совсем.
Файловая система не предназначена для хранения большого количества мелких экземпляров. Во-первых, оверхеад, во-вторых, скорость низкая, в-третьих, репликация это ужас. Есть несколько ФС, решающих часть проблем (btrfs, например, или gfs), но они нестабильны просто или в плане скорости.
Кто вам сказал, что я храню 2 млрд файлов на файловой системе?
Мы храним в MongoDB файлы даже по 500кб. Есть нюансы, конечно, но как решение в целом на данный момент эффективность максимальная.
Вы в монгу сможете положить 2млрд записей по 3 кб?
Последовательное чтение используется для парсера лога, например. Естественно, писать надо так, чтобы потом быстро читать. В MongoDB последовательная обработка тоже возможна, но есть нюансы.
Чаще всего если данные надо хранить в большом объёме — то доступ к ним будет случайный. А если чтения всё равно не получится оптимизировать — то надо оптимизировать хотя бы запись, делая её линейной.
Не могу! Вы написали конечный объём в 50 терабайтов, за день это или за год, у меня данных нет. Но это всё равно про Линукс, написал уже два или три раза, что проблемы записи в Windows, используемом автором статьи.
Монгу вы под линуксом запускаете или под виндой?
Об этом я написал в самом начале, вера опыт не заменяет. Скопируйте образ BR диска, например, и посмотрите, что будет с системой происходить. Чтобы два раза не вставать, советую смотреть счётчик Available для памяти в Task manager.
Про отключение writeback занятная теория (отключение WB, сюрприз!, не помогает), есть способ лучше =) O_DIRECT.
Вы отключаете writeback и у вас всё равно остаётся много грязных страниц? Видимо, как-то не так отключаете. Вы случаем не во временный файл писали? Если проблема действительно есть — то дайте ссылку, мне сходу ни одной не попалось.
Ну раз вы начали рассуждать про записи и чтения — то давайте начнём с того, как именно у вас хранятся данные на диске, без этого рассуждать о том, что readahead всегда вредит как-то странно. А вот про описанную ситуацию — это вы зря, она более чем реальна. Надо хранить много (по 2 млрд на машину) объектов размером в несколько килобайт (средний размер пусть будет 3кб). Ваши варианты, как это положить на диск?
Далее у вас началась последовательная обработка данных. Как часто она случается в MongoDB? Можно ли в принципе так положить данные, к которым производится произвольный более-менее равномерный доступ, на диск так, чтобы их можно было последовательно считывать большими кусками? Кстати, про шедулер: какой шедулер стоит при этом применять и почему, какой при этом будет профит?
Про нюанс «в час» — можете сами посчитать, а могу сразу сказать: на систему, которая была второй в предыдущем посте, постоянно льётся 3-5гб/ч, в пиках — больше. Но там маленькие записи, дискам сложно переваривать бОльшие объёмы из-за IO. В других местах, где записи по несколько мегабайт — конечно гигабайты в час легко получаются, когда начинают контент заливать.
А в Windows то вы с заканчивающейся памятью на диск писали или в сеть? В оригинальной статье всё же шёл разговор о работе с диском. В то, что в Windows хреново написан file cache, простите, не верю. Вот если кто-то накрутил настройки lazy write — тогда вполне возможны проблемы с большим количеством грязных страниц. В любом случае, настраивать надо периодичность flush, а не отключать writeback. А диски — они одинаковые, проблемы при работе с ними слабо зависят от операционной системы.
А на сколько для обычного ssd отличается запись 2 секторов за 2 операции и за одну операцию? И я не уверен, что в ядре технически просто быстро писать на диск что-то не кратное 4кб страницам.
Кстати, у вас в расчётах ошибочка:) Даже если будет write aplification = 3 то 2к записей + 2к чтений превратятся в 8к операций на SSD (а то и меньше, не все чтения туда попадут). Думаю, можно добиться write aplification = 2. Можно и 1, но тут вступает в силу вопрос из первого абзаца этого комментария.
Под «зачем» я имел в виду «зачем обозначать как dirty после ребута», т.к. они ещё до ребута были известны и записаны.
У SSD вероятность спасения данных в случае зеркала сильно ниже, чем у обычных крутящихся дисков. У коллеги как-то раз померли в зеркале сразу оба SSD диска :) Нагрузка же на них совершенно одинаковые, диски обычно из одной партии => помирают примерно одновременно.
Мне кажется, эту проблему должен решать сам bcache. У SSD ведь есть алерты, что оно вот-вот умрёт? Как только такое появляется — сбрасывать все dirty страницы на диск, отключать режим writeback и кричать в консоль админу, что всё плохо и пора купить новый диск.
А вот можно ли запихнуть в bcache md-девайс — большой вопрос, он же и сам md-устройство уже. Ещё нам бы очень хотелось, чтобы можно было заюзать 1-2 SSD диска в качестве кэша для 24 обычных, которые не собраны в рейд.
А зачем? Ведь если по-умолчанию при старте считать, что все блоки dirty — то нету никакой проблемы, вы получите все данные с диска + изменённые блоки из ssd кэша. Если вдруг блоки окажутся одинаковыми — то никакой проблемы нету, если разные — то правильное содержание в ssd. Тут только 1 тонкий момент — надо на ssd хранить соответствие закешированного блока и блока на диске, а не только в оперативной памяти. И никакого replay делать не надо — только поднять список соответствия в память и сразу продолжить работу.
С барокамерой мимо. Как показывает график фазовых состояний воды, при низких давлениях и температуре ниже ноля в жидком виде вода находиться не может. Более того, можете сами провести опыт: поставить в камеру миску с водой и откачать воздух — вода очень быстро превратится в лёд.
Вы не в курсе, можно ли запилить это так, чтобы люцен проиндексировал содержимое строчки лога? Масштабироваться, на сколько я знаю, он должен действительно неплохо.
Специально сейчас на Win7 скопировал с сетевой шары на локальный диск 400мб файл, ближе к концу копирования действительно было мало Allocated памяти, но через минуту после копирования Allocated = Cached + Free, то есть грязных страниц не осталось. Все ссылки, что вы привели — про то, что File Cache занимает весь доступный объём ОЗУ и приложениям, которые предварительно резервировали себе память, ничего не достаётся и они даже в файл подкачки вытесняются. Ну так это же нормально, оно так и должно работать! Файловый кэш выедает всю свободную память, чтобы она не простаивала, для ускорения операции записи. Если не нравится — уменьшайте объём памяти, который готовы выделять под буферы, делайте синк на диск чаще, инструменты то есть для этого.
Вы готовы привести другие ссылки, где будет написано про большое количество грязных страниц в памяти после окончания процесса копирования? Или, может быть, готовы показать ссылку, где будет описано, что страницы не сбрасываются на диск, когда вызывается sync? Мне такие не попадались.
По вашим ответам складывается ощущение, что вы считаете себя большим специалистом в области программирования, но при этом плохо понимаете, как работает файловых кэш. Вы много раз повторили про случайный доступ к диску, про монго, но ни разу не описали структуры данных, к которым тот самый случайный доступ производится. Вы опять же голосновно объявили cfq «десктопным» шедулером, хотя только он, в текущий момент, поддерживает io приоритеты.
Можете не отвечать, но советую всё же разобраться с «магией», которую применяют во всех современных операционных системах много лет, и с которой успешно работают миллионы программистов по всему миру. Расширьте кругозор. И не стоит учиться этому у разработчиков MongoDB, это далеко не самая лучшая база данных.
©Linux Torvalds
sendfile, кстати, через readahead работает. Примеры, когда readahead будет хорошо работать: вычитывание b-tree индекса, подгрузка какой нибудь игрой ресурсов из большого ресурсного файла. В обоих случаях доступ рандомный, да не совсем.
Кто вам сказал, что я храню 2 млрд файлов на файловой системе?
Вы в монгу сможете положить 2млрд записей по 3 кб?
Чаще всего если данные надо хранить в большом объёме — то доступ к ним будет случайный. А если чтения всё равно не получится оптимизировать — то надо оптимизировать хотя бы запись, делая её линейной.
Монгу вы под линуксом запускаете или под виндой?
Вы отключаете writeback и у вас всё равно остаётся много грязных страниц? Видимо, как-то не так отключаете. Вы случаем не во временный файл писали? Если проблема действительно есть — то дайте ссылку, мне сходу ни одной не попалось.
Далее у вас началась последовательная обработка данных. Как часто она случается в MongoDB? Можно ли в принципе так положить данные, к которым производится произвольный более-менее равномерный доступ, на диск так, чтобы их можно было последовательно считывать большими кусками? Кстати, про шедулер: какой шедулер стоит при этом применять и почему, какой при этом будет профит?
Про нюанс «в час» — можете сами посчитать, а могу сразу сказать: на систему, которая была второй в предыдущем посте, постоянно льётся 3-5гб/ч, в пиках — больше. Но там маленькие записи, дискам сложно переваривать бОльшие объёмы из-за IO. В других местах, где записи по несколько мегабайт — конечно гигабайты в час легко получаются, когда начинают контент заливать.
А в Windows то вы с заканчивающейся памятью на диск писали или в сеть? В оригинальной статье всё же шёл разговор о работе с диском. В то, что в Windows хреново написан file cache, простите, не верю. Вот если кто-то накрутил настройки lazy write — тогда вполне возможны проблемы с большим количеством грязных страниц. В любом случае, настраивать надо периодичность flush, а не отключать writeback. А диски — они одинаковые, проблемы при работе с ними слабо зависят от операционной системы.
Кстати, у вас в расчётах ошибочка:) Даже если будет write aplification = 3 то 2к записей + 2к чтений превратятся в 8к операций на SSD (а то и меньше, не все чтения туда попадут). Думаю, можно добиться write aplification = 2. Можно и 1, но тут вступает в силу вопрос из первого абзаца этого комментария.
У SSD вероятность спасения данных в случае зеркала сильно ниже, чем у обычных крутящихся дисков. У коллеги как-то раз померли в зеркале сразу оба SSD диска :) Нагрузка же на них совершенно одинаковые, диски обычно из одной партии => помирают примерно одновременно.
Мне кажется, эту проблему должен решать сам bcache. У SSD ведь есть алерты, что оно вот-вот умрёт? Как только такое появляется — сбрасывать все dirty страницы на диск, отключать режим writeback и кричать в консоль админу, что всё плохо и пора купить новый диск.
А вот можно ли запихнуть в bcache md-девайс — большой вопрос, он же и сам md-устройство уже. Ещё нам бы очень хотелось, чтобы можно было заюзать 1-2 SSD диска в качестве кэша для 24 обычных, которые не собраны в рейд.