Иванов Андрей ivanov

Может, это повод вернуться обратно и нормально жить, а не тратить всё личное время на поездку в офис =)

Его Приус в Калифорнии.

Уже несколько раз написал — в том, что не работает =)
Точнее, лишь позволяет отсрочить смерть, а помогает от захламления памяти только O_DIRECT.

ближе к концу копирования действительно было мало Allocated памяти, но через минуту после копирования Allocated = Cached + Free, то есть грязных страниц не осталось

На сервере не бывает «через минуту», пишется непрерывно.

Это переводится как «я не знаю»?

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

Спасибо за новую шутку. Раньше мне нравилась «Стив Джобс сказал, что вам это не надо», теперь к ней будет «Линукс Торвальдс сказал, что это работает» =) Кроме самой прекрасной фразы вы ещё подсказали, что и имя можно написать с ошибкой для пущего эффекта ;)

Не смог удержаться =) Вместо поиска информации про MongoDB (и расширения кругозора) вы стали искать информацию про простой и понятный для повторения пример. Не получилось.

social.technet.microsoft.com/Forums/ru/sqlru/thread/7721af71-6eaa-48a0-85c1-b231ef23b85e
social.technet.microsoft.com/Forums/ru/ws2008r2ru/thread/1bef70b4-932e-4104-996e-1fadb1fda9d2
social.technet.microsoft.com/Forums/ru-RU/ws2008r2ru/thread/cd60a4a5-4bb4-4ad9-b498-457bdf141c89
social.technet.microsoft.com/Forums/ru-RU/ws2008r2ru/thread/3fc0a8be-8d32-4ab5-be93-de51dc82128b
social.technet.microsoft.com/Forums/ru/sqlru/thread/7721af71-6eaa-48a0-85c1-b231ef23b85e
Часть примеров про SQL Server, так как он отличный индикатор описанной проблемы.

MongoDB, к слову, на Windows работает для галочки, как только начинается серьёзная запись, сервер умирает.

Ответов больше не будет, не обессудьте.

Как хранит данные MongoDB, можно почитать в интернетах.
О том, что RA вредит случайному доступу, очевидно и ребёнку, о том, что RA не помогает, я вам написал несколько раз — при линейном чтении от RA никакого толка, потому что линейно всегда читается большими блоками.

Файловая система не предназначена для хранения большого количества мелких экземпляров. Во-первых, оверхеад, во-вторых, скорость низкая, в-третьих, репликация это ужас. Есть несколько ФС, решающих часть проблем (btrfs, например, или gfs), но они нестабильны просто или в плане скорости.
Мы храним в MongoDB файлы даже по 500кб. Есть нюансы, конечно, но как решение в целом на данный момент эффективность максимальная.

Последовательное чтение используется для парсера лога, например. Естественно, писать надо так, чтобы потом быстро читать. В MongoDB последовательная обработка тоже возможна, но есть нюансы.

Кстати, про шедулер: какой шедулер стоит при этом применять и почему, какой при этом будет профит?

Я не справочное бюро =) А так для линейного чтения в один поток по фигу, что за шедулер.

Про нюанс «в час» — можете сами посчитать

Не могу! Вы написали конечный объём в 50 терабайтов, за день это или за год, у меня данных нет. Но это всё равно про Линукс, написал уже два или три раза, что проблемы записи в Windows, используемом автором статьи.

А в Windows то вы с заканчивающейся памятью на диск писали или в сеть?

Диск.

В то, что в Windows хреново написан file cache, простите, не верю.

Об этом я написал в самом начале, вера опыт не заменяет. Скопируйте образ BR диска, например, и посмотрите, что будет с системой происходить. Чтобы два раза не вставать, советую смотреть счётчик Available для памяти в Task manager.

Про отключение writeback занятная теория (отключение WB, сюрприз!, не помогает), есть способ лучше =) O_DIRECT.

Магия это технология, которая не работает, как анонсируется. Конечно же, я знаю, как readahead работает. Последовательное чтение на серверах читают мегабайтами, а не как удобно. «Как удобно» делают только когда скорость не имеет значения.

Итак, практика: 100 IOPS random read дадут вам 3 мб/с, 100 IOPS последовательных чтений дадут 30 мб/с при сравнимой latency. Что это говорит? Что время чтения 1 сектора сильно меньше времени позиционирования головки. У вас другая реальность?

Это практика чего? Синтетического теста? У меня реальность другая, да. Чтения никогда не бывают без записей, такие нюансы придают бодрости на первой встрече с реальностью. Вы написали очевидный факт, непонятно зачем. Я утверждал исключительно о том, что readahead на сервере только вредит. В следующий раз, когда захотите блеснуть эрудицией, упомяните ещё промахи позиционирования головки, на современных дисках с ростом плотности актуальность всё больше.

NCQ, кстати, замедляет доступ к диску, зато даёт возможность сделать больше IO операций в секунду. Latency при включении NCQ растёт, т.к. появляется ещё одна очередь запросов.

Велик и могуч русский язык =) Увеличение задержки чтения и уменьшение количества прочитанных байтов есть замедление. Просто зависит от ситуации, что важнее.

Но читать с диска сразу мегабайты/гигабайты, как-то кешировать внутри своей системы, следить за этим — это переписывать pagecache операционной системы.

Последовательное чтение мегабайтами используется для последовательной обработки данных. Не надо ничего переписывать. Вы рассуждаете про общие теории ни о чём. Я утверждаю, что когда может помочь readahead, он не имеет смысла. И утверждаю, что вы агитируете за использование магии, потому что нет опыта её применения. Ни один из ваших «советов» нельзя применить к опыту, описанному в статье, потому что опыт на Windows и говорить «а вот у меня в Линуксе много пишется и с памятью всё хорошо» демагогия.

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

Когда у нас индексы перестанут помещаться в память, всё встанет колом =) Тем не менее, ручным кэшированием обычно заниматься, ясное дело, неразумно.

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

Без деталей это данные ни о чём. Запросы к БД должны измеряться тысячами в секунду, обращения к просто файлам измеряться десятками килобайтов хотя бы (иначе зачем файлы?). Описанная вами ситуация ни рыба, ни мясо.

Коллега, linux kernel hacker, тоже считает, что надо по-максимуму использовать то, что даёт сама операционная система, и что её писали далеко не глупые люди.

Невероятное знание! =)
IO-шедулер в серверной Убунте по умолчанию стоит десктопный, для единообразия. Дураков хватает везде. Тем не менее, я уважаю авторов Линукса, потому что в целом достойный результат.

Кстати, на счёт вашего выпада в первом посте про десятки гигабайт… У меня обычно по полсотни терабайт данных на сервер. И по несколько сотен тебарайт на кластер.

Там был нюанс «в час». Либо вы в юношеском задоре пропустили этот нюанс, либо я сильно устарел и не в курсе, что уже можно писать по 15 гигабайтов в секунду на один сервер. Напомню ещё, что это было про Windows, который используется в обсуждаемом материале.

Обращения на локалхост идут мимо сетевой карты =)
Зато была бы возможность осуществлять вызовы по сети, когда оно понадобится.

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

Про RA — диски шпиндельные, с секторами по 4к. В теории наверное да, несколько секторов прочитать времени занимает столько же, в реальности нет.

На практике, знаете ли, в здравом уме не читают последовательно блоками по 1 сектору, читают мегабайтами обычно. И пишут тоже. Есть нормальные понятные технологии, типа NCQ, чтобы ускорять доступ к диску. RA это магия.

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

Когда память понадобится — быстренько освободится.

В теории так, да =) Пока не столкнулся с этим, тоже так думал. В Linux свои «оптимизации», про доступную память при активной записи я говорил в Windows. В Task manager есть счётчик доступной памяти (Available), это чистые страницы или готовые в любой момент к возврату пользователю, грубо говоря, кэш чтения. Кэш записи просто так на диск не сбросить, особенно в контексте «поставить больше оперативки», когда скинуть на диск надо 90 гигабайтов. Free без разницы, какое значение имеет.

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

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

Да нормально я вас оцениваю =) Вы выложили тесты на базе 200 мегабайтов, это не очень разумно, слишком мало данных.

Одинаковые версии серверов это не самое страшное, я бы для первичного тестирования сделал то же самое.

Со сравнения массивов я и начал переписку с вашим оппонентом, считаю, что в этом споре он неправ.

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

Под заканчивающейся памятью имею в виду именно заканчивающуюся доступную память, а что ещё можно иметь в виду? ;) Гигабайты записи просто файлов. В Windows. Как расположены, по барабану, это просто такая «оптимизация» для SMB, фиг отключишь. Writeback, который «решает все проблемы» =)

«Меряться представлениями» это прекрасно =)

У меня в инструкции к телеку LG написано, что не рекомендуется использовать статические картинки. Иначе останутся навсегда. Даже частый просмотр фильмов 4:3 на экране 16:9, говорят, может привести к полосам на экране. Думал, такое у всех =) Теперь вот думаю, не сдать ли его, пока есть возможность, или лениться и экспериментировать ;)

Вызов fadvise завершается успешно, но ядро на это не обращает внимания.
MongoDB ничего не считает, просто использует memory mapping с соответствующим вызовом madvise. Виновата магия readahead, которую я не могу понять с давнишних времён первой встречи на рейд-контроллерах.

Писал вам, естественно =) Последний абзац указывает на то, что вы верите в магию. Что поможет readahead или там больше памяти. Это верно очень недолго, или на десктопных приложениях, когда постоянной нагрузки нет.
Суть затеи в том, если много писать просто так, в Windows заканчивается оперативная память. Гигабайты в час имелись в виду, а не вообще.

Написал и понял, что мы в разных мирах живём. В обсуждении статьи про ПО, тестируемое на 200 метрах данных вполне нормально давать советы поставить больше оперативки. Извините, что влез со своим представлением о высокой нагрузке.

Когда у вас много параллельных чтений, нагрузка распределяется сама собой и никакого выигрыша от предложенной в статье «асинхронности» не будет. А когда читаете в один поток, разница будет зависеть от времени обработки — чем больше время обработки, тем больше разница, но не более, чем в два раза. Если вы читаете и пишете одновременно, разница будет до 4 раз.

Одинаковые, потому что уверен, что они не ставили разные версии для тестирования =) Замеры на базе в 200 метров, а в предисловии про терабайтные базы — думаю, что разные версии серверов не такой забавный челлендж будет, как проблема локальности, когда продукт конкурентов перестанет отставать =)

Про сравнение массивов — они просто в начале пути, я полагаю =) Про понимать — это нужно обычно везде ;)

Предположу, что потому что версии SQL Server одинаковые, они одинаково обрабатывают входящие данные.

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

Я тоже полагаю, что сравнение двух массивов байтов перед сравнением XML даст огромный прирост производительности. Если не даст, надо делать какие-то трюки и всё равно приходить к тому, чтобы сравнивать не XML, а что-то попроще.

Эта статья про то, как одни безрукие программисты тягались с другими безрукими программистами, тем не менее, я считаю, что спор про сравнение массивов вы проиграли =)

Вот-вот. Всего лишь сотни и тысячи запросов.
Вместо десятков тысяч на MongoDB, например.

Конкатенация раз в 50-100 примерно быстрее форматной строки для записи в журнал.
А если писать в журнал сразу байтики, без конкатенации, то будет быстрее в 1000 раз, чем с конкатенацией =)

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

Самый быстрый способ работы с файлами это memory mapping.

Readahead, например, из вашего рассказа, это магия, недоступная простым смертным. Эту прекрасную неотключаемую «фичу» в ядре Линукса мы обычно закручиваем до минимума, потому что она упарывает производительность БД на ровном месте.
Когда поработаете с десятками гигабайтов данных, почувствуете «эффективность» и остальных перечисленных «фич». Статья про максимальную производительность, а не про лабораторные работы в школе.

НЭП закрыли по другой причине, читайте историю =) После смерти Ленина многое изменилось.

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

Считаю, что отбивая интерес у самых желающих, ничего, кроме закрытия, компанию не ждёт. Пойду смотреть, что за телефоны на WP8 у Самсунга, он любит копировать дизайн, может дизайн N9 тоже использовал «для вдохновления» =)

Всё там хорошо с отпечатками, они ужасно достают, особенно на жёлтом.
Но какая разница, их всё равно не продают.

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

XCode пока черпает идеи у VS =) Скоро они переместят SE вправо, готовьтесь. Интерфейс в MDI к 4-й версии организовали.

Забыли упомянуть ещё одну важную и очень бурную область, телефоны.
Там тоже всё просто уже. Во всяком случае, для современных операционок Microsoft, Apple и Google.

Сложные переносы блоков я не буду исследовать через окно коммита. По большому счёту, перед коммитом проводится последняя инспекция на предмет «а не забыли ли мы скальпель у пациента внутри?»

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

Когда мы только перешли на Subversion, я с трудом понимал эти плюсики. Но взаимодействие с миром open source, где не работает абсолютно всё, научило с ними спокойно обходиться. К примеру, только в первую неделю знакомства с MongoDB было отправлено пяток патчей разработчикам и клиента, и сервера.

А посмотреть большой дифф в отдельном окне можно и в TortoiseHG, это делается всё тем же даблкликом по файлу или правый клик -> левый клик. Вы в одном из комментариев выше были за возможность выбора =) Вот TortoiseHG эту возможность и предоставляет.

Я думал, вы видели окно коммита в TortoiseHG =)

Это не только к окну коммита относится. Check modifications должно работать аналогично, там тоже список файлов на потенциальный коммит. Я писал только про окно коммита, потому что часто им пользуюсь вместо Check modifications — не надо лезть в подменю, если в проводнике, плюс в VS хоткей биндится на коммит.

А вменяемым он станет сразу, как только для дифа не будет нового окна. Тогда не придётся никому запоминать, как работает даблклик в списке файлов, летать про клавиатуре или с мышки на клавиатуру и обратно. А если ещё и диф при этом будет показывать только изменения, то совсем хорошо. Использовать в этом месте «большой» диф со всем кодом и его изменениями мне кажется мешающей избыточностью.

Вы случайно не родственник товарищу, который мне выше раз 7 написал, что я чего-то не понимаю из детского мануала к Mercurial или TortoiseHG? Вроде написали про желание понять причину моего заявления, а не про повышение самооценки за мой счёт. Надеюсь, я достаточно внятно выразился, что «не можете запомнить», «не понимаете» и прочие подростковые способы ведения диалога его закончат.

Начался наш диалог с мышки. Поэтому я и привёл примером паттерн работы только с мышкой. Упоминание стрелок исказило картину =)

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

Что имеем с SVN/Git. Использование с мышкой описал раньше. Если использовать Enter/стрелки и Esc, надо правую руку убирать с мышки на Enter/стрелки и листать клавиатурой. Потому что левая рука на Esc, потому что летать по клавиатуре левой рукой и/или правой рукой мышка<->клавиатура неудобно. Листание клавиатурой дискомфортное, потому что нет плавности и приходится напрягаться.

При любом раскладе в SVN/Git либо активный пиксельхантинг, либо в глазах рябит из-за листания клавиатурой.

И ещё про «запомнить»: «Знание нескольких принципов освобождает от знания многих фактов». Используя это правило можно не забивать голову мусором, выбирая правильно реализованные инструменты. Пользоваться неправильно (или непривычно) реализованными инструментами это мешает, ясное дело, но в целом по жизни так эффективнее. Из-за редкого столкновения с отсутсвием единообразия поведения запомнить место его проявления не довелось.

Как в TortoiseHG, одним левым кликом по файлу с возможностью листания клавиатурой.
А не правый клик -> левый клик -> левый клик (закрыть окно).

Ещё можно даблкликом воспользоваться, но он не везде работает одинаково (в некоторых окнах открывает не дифф, а файл на редактирование), поэтому заставляет задумываться, можно ли даблкликать или надо правым кликом и потом из меню левым.

А, с таким я никогда не сталкивался =) У меня все проекты гомогенные. А даже если бы и были гетерогенными, то пользовался бы встроенными в HG средствами для работы с внешними репозиториями на SVN. В таком случае офлайн-фича Mercurial никуда не теряется из-за одного проекта на Subversion.

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

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

TortoiseSVN лучше остальных и с ним работает плагин VisualSVN. То, что всё остальное ещё хуже не значит, что TortoiseSVN предел мечтаний.

А какая версия? У меня 1.7.7, параллельно с HgScc работает нормально.

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

Это порт TortoiseSVN, слишком много возни с мышкой.
Я не один такой уникальный, кто смотрит диффы при коммите, судя по TortoiseHG.

У HG можно жать на кнопку коммита в тулбаре (а ещё лучше биндить хоткей), потому что, как я понял из документации, коммит идёт сразу всему, а не только выбранному файлу.

Возможно, я и в SVN работаю так, как надо работать в Mercurial, поэтому разницы не ощущаю =) Но у меня пока мало опыта с HG, перенёс на него домашние штуки и время от времени ими занимаюсь. С другой стороны, о невозможности для меня пользоваться AnkhSVN я понял на второй день.

Я ею и пользовался, пока писал. А потом посреди правок случайно нажал опубликовать.
Кнопка «сохранить» должна быть единственной сохраняющей. А тип сохранения должен быть там же примерно, где и раздел, куда публикуешь.

Просто наши Вселенные слабо пересекаются =)
В моей Вселенной про устриц может подсказать Яндекс.

Когда вы работаете в Проводнике Windows, удобнее пользоваться инструментом, который расположен «в Проводнике». Для повседневной работы в IDE или в консоли он не нужен, ясное дело.

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

Кардинальная разница между VisualSVN и HgScc в наличии на тулбаре у первого переключателя между бранчами. Я его выключаю сразу, чтобы весь тулбар помещался на одной строке. Разрешение 1600.