Во всём. Деньги дали борцам за разнообразие, они наняли сценаристов таких же, актёров и дальше по списку.
Все они или почти все не очень талантливые, поэтому фильм и набрал 2 балла у зрителей — цель сделать инклюзивный фильм, а не этот ваш цисгендерный блокбастер увенчалась успехом.
Копить ошибки это стремительно катиться к провалу, потому что «мелкие» ошибки будут у всех.
Яндекс не нейросеть для программирования всего, там много команд со своими прибаутками, тысячи багов на весь Яндекс маловероятно, а на одну клавиатуру точно нет.
Пульс на вашем уровне показывает ничего. Любая серьезная нагрузка его поднимает до неба, потому что никакая из систем к нагрузке не готовы, а у мозга есть всего два способа вам помочь — поднять частоту дыхания и частоту пульса.
Смотрите на свои ощущения. Вам должно быть по кайфу бежать, пульс будет такой, какой нужен в текущей ситуации — мозг не дурак и всё сделает как надо.
Стало тяжело, идите шагом. Отдохнули и захотелось бежать, бегите. Ограничением используйте не пульс, а разговорный тест — можете остановиться и ответить маме/жене/подруге/другу по телефону, значит всё ок. Если надо две минуты стоять согнувшись перед ответом, значит время бега или его интенсивность следует уменьшать.
Мой пульс вам ничем не поможет, потому что у вас зоны свои. За три-четыре минуты быстро поднимается до 160, дальше почти до конца плавно растёт до 170 и последние две минуты поднимается до 174-180, в зависимости от погоды и моего состояния. Это соревнование раз в месяц, тренировки я так не бегаю.
Без опыта оценивать свои усилия по пульсу вы будете сильно хуже, чем субъективно по дыханию и уровню дискомфорта.
65 кг вам не нужно. Вес будет такой, какой ваш. Смотрите в зеркало — если там всё нравится, какой вес без разницы.
Чужие скорости не смотрите тоже. 50 минут на десятке хорошее время, вы будете подготовлены лучше 80% населения планеты и жить будете по верхней границе своей генетики.
Не режьте углеводы, это восстановление в том числе. Достаточно просто не есть регулярно торты/булки, сахар и сладкую воду, чтобы не набирать вредный вес.
Типичную тренировку вашу описал в комментарии себе. Когда выйдете на 3-4 тренировки в неделю, план надо корректировать.
Для здоровья и с 2-3 тренировками в неделю описанным способом можно жить всю жизнь без тренеров и кучи времени на изучение бесполезных правил бега на пульсе 120, которые все бездумно тиражируют.
2 часа мучений на второй части марафона лучше заменить на 50 минут кайфа десятки. Марафон для стариков, которые одинаково бегут что 10км, что марафон.
Тренировки на вашем уровне лучше использовать шагобег. Бежать по кайфу, а когда кажется, что становится тяжело, переходишь на шаг и так 30 минут, лучше 50. 8 км/ч не бег, минимум 10 км/ч, а лучше 11.
Интервальные тренировки (а выше описана именно она) самые эффективные с небольшим количеством дней.
Мышцы ног теряются у подготовленных атлетов из силовых видов спорта, с дивана мышцы растут от чего угодно, интервальные беговые тренировки развивают мышцы не хуже силовых первое время.
Тошнить по 8-9 км/ч уместно, когда тебе 70 и тренировок в неделю 15 +часов.
Не есть углеводы не очень умно — это основной источник энергии и в калораже должны быть 50-70%. Без углеводов жить тяжело, тренироваться тем более. Бодибилдеры убирают углеводы на очень короткий срок, перед соревнованиями, без углей жизнь очень грустная, ещё и результаты падают.
Начал бегать в 37, когда перестало нравится отражение в зеркале. Сейчас 45. 10км бегу за 38 минут, в неделю 7-8 часов тренировок.
Рост174. Вес 65-66 — с начала тренировок вес стал больше, жира стало меньше. Смотреть надо в зеркало, а не на весы.
ближе к концу копирования действительно было мало Allocated памяти, но через минуту после копирования Allocated = Cached + Free, то есть грязных страниц не осталось
На сервере не бывает «через минуту», пишется непрерывно.
Нам бессмысленно продолжать дискуссию. Спорить с детьми я могу и без интернетов, дома. Хинт — не надо общаться вопросами, надо общаться утверждениями, вероятность ошибки значительно выше, это отличный показатель ответственности за свои слова.
Спасибо за новую шутку. Раньше мне нравилась «Стив Джобс сказал, что вам это не надо», теперь к ней будет «Линукс Торвальдс сказал, что это работает» =) Кроме самой прекрасной фразы вы ещё подсказали, что и имя можно написать с ошибкой для пущего эффекта ;)
Не смог удержаться =) Вместо поиска информации про MongoDB (и расширения кругозора) вы стали искать информацию про простой и понятный для повторения пример. Не получилось.
Как хранит данные 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 без разницы, какое значение имеет.
Конечно, я считаю, что это очень плохо, когда система всю свою оперативку использует под «грязные» страницы. Это плохо во всех отношениях, и пропадание питания чревато потерей очень большого количества данных, и доступной оперативки для приложений нет, и кэша чтения тоже нет.
Дык, и приводили бы этот пример. С какими-нибудь нюансами, типа количества таблиц, максимального количества строк в таблицах или ещё чего-нибудь интересного на абзац текста.
Выглядело бы значительно ближе к реальности.
Это на развитие интернета в России на благо всего населения!
Во всём. Деньги дали борцам за разнообразие, они наняли сценаристов таких же, актёров и дальше по списку.
Все они или почти все не очень талантливые, поэтому фильм и набрал 2 балла у зрителей — цель сделать инклюзивный фильм, а не этот ваш цисгендерный блокбастер увенчалась успехом.
Красиво 🤗
Вот бы всё всегда было так просто. Приехал в Антарктику и ходишь как пингвин в фраке. Вьюга, снегопад, а ты в своей клинической зоне!
Мнение обывателя, который придумал себе ограниченный мир :)
Все бегают по разным причинам.
Это очень неприятно, когда ты любишь медали, вешаешь их на специальную стену, а какой-то чувак приходит и обесценивает твою любовь своими ожиданиями.
Читающие комментарии — идите по пути Даши или по ещё тысяче путей в беге, меньше слушайте «экспертов», ограничивающих ваше вдохновение.
Ошибки исправляются в первую очередь.
Копить ошибки это стремительно катиться к провалу, потому что «мелкие» ошибки будут у всех.
Яндекс не нейросеть для программирования всего, там много команд со своими прибаутками, тысячи багов на весь Яндекс маловероятно, а на одну клавиатуру точно нет.
Суставная гимнастика и приседания для прогрева «рабочих поверхностей» здесь и сейчас перед активностью и настройка на тренировку, а не ОФП.
ОДА очень прочный и плохо себя чувствовать начнёт внезапно и надолго.
Пульс на вашем уровне показывает ничего. Любая серьезная нагрузка его поднимает до неба, потому что никакая из систем к нагрузке не готовы, а у мозга есть всего два способа вам помочь — поднять частоту дыхания и частоту пульса.
Смотрите на свои ощущения. Вам должно быть по кайфу бежать, пульс будет такой, какой нужен в текущей ситуации — мозг не дурак и всё сделает как надо.
Стало тяжело, идите шагом. Отдохнули и захотелось бежать, бегите. Ограничением используйте не пульс, а разговорный тест — можете остановиться и ответить маме/жене/подруге/другу по телефону, значит всё ок. Если надо две минуты стоять согнувшись перед ответом, значит время бега или его интенсивность следует уменьшать.
Мой пульс вам ничем не поможет, потому что у вас зоны свои. За три-четыре минуты быстро поднимается до 160, дальше почти до конца плавно растёт до 170 и последние две минуты поднимается до 174-180, в зависимости от погоды и моего состояния. Это соревнование раз в месяц, тренировки я так не бегаю.
Без опыта оценивать свои усилия по пульсу вы будете сильно хуже, чем субъективно по дыханию и уровню дискомфорта.
65 кг вам не нужно. Вес будет такой, какой ваш. Смотрите в зеркало — если там всё нравится, какой вес без разницы.
Чужие скорости не смотрите тоже. 50 минут на десятке хорошее время, вы будете подготовлены лучше 80% населения планеты и жить будете по верхней границе своей генетики.
Не режьте углеводы, это восстановление в том числе. Достаточно просто не есть регулярно торты/булки, сахар и сладкую воду, чтобы не набирать вредный вес.
Типичную тренировку вашу описал в комментарии себе. Когда выйдете на 3-4 тренировки в неделю, план надо корректировать.
Для здоровья и с 2-3 тренировками в неделю описанным способом можно жить всю жизнь без тренеров и кучи времени на изучение бесполезных правил бега на пульсе 120, которые все бездумно тиражируют.
Структура тренировки обычная.
2-3 минуты суставная гимнастика и 5-20 приседаний.
10-20 минут бодрым шагом — начинать с прогулочного, заканчивать 7-8 км/ч.
1-2 минуты отдохнуть, сделать несколько глотков воды, если надо.
10-20 минут шагобег
1-2 минуты отдохнуть, сделать несколько глотков воды, если надо.
10-20 минут заминка, в обратную сторону от разминки.
Время рабочих этапов зависит от общего времени тренировки. Можно поровну для начала, с опытом найдёте свой ритм.
2 часа мучений на второй части марафона лучше заменить на 50 минут кайфа десятки. Марафон для стариков, которые одинаково бегут что 10км, что марафон.
Тренировки на вашем уровне лучше использовать шагобег. Бежать по кайфу, а когда кажется, что становится тяжело, переходишь на шаг и так 30 минут, лучше 50. 8 км/ч не бег, минимум 10 км/ч, а лучше 11.
Интервальные тренировки (а выше описана именно она) самые эффективные с небольшим количеством дней.
Мышцы ног теряются у подготовленных атлетов из силовых видов спорта, с дивана мышцы растут от чего угодно, интервальные беговые тренировки развивают мышцы не хуже силовых первое время.
Тошнить по 8-9 км/ч уместно, когда тебе 70 и тренировок в неделю 15 +часов.
Не есть углеводы не очень умно — это основной источник энергии и в калораже должны быть 50-70%. Без углеводов жить тяжело, тренироваться тем более. Бодибилдеры убирают углеводы на очень короткий срок, перед соревнованиями, без углей жизнь очень грустная, ещё и результаты падают.
Начал бегать в 37, когда перестало нравится отражение в зеркале. Сейчас 45. 10км бегу за 38 минут, в неделю 7-8 часов тренировок.
Рост174. Вес 65-66 — с начала тренировок вес стал больше, жира стало меньше. Смотреть надо в зеркало, а не на весы.
Точнее, лишь позволяет отсрочить смерть, а помогает от захламления памяти только O_DIRECT.
На сервере не бывает «через минуту», пишется непрерывно.
Нам бессмысленно продолжать дискуссию. Спорить с детьми я могу и без интернетов, дома. Хинт — не надо общаться вопросами, надо общаться утверждениями, вероятность ошибки значительно выше, это отличный показатель ответственности за свои слова.
Спасибо за новую шутку. Раньше мне нравилась «Стив Джобс сказал, что вам это не надо», теперь к ней будет «Линукс Торвальдс сказал, что это работает» =) Кроме самой прекрасной фразы вы ещё подсказали, что и имя можно написать с ошибкой для пущего эффекта ;)
Не смог удержаться =) Вместо поиска информации про 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 работает для галочки, как только начинается серьёзная запись, сервер умирает.
Ответов больше не будет, не обессудьте.
О том, что RA вредит случайному доступу, очевидно и ребёнку, о том, что RA не помогает, я вам написал несколько раз — при линейном чтении от RA никакого толка, потому что линейно всегда читается большими блоками.
Файловая система не предназначена для хранения большого количества мелких экземпляров. Во-первых, оверхеад, во-вторых, скорость низкая, в-третьих, репликация это ужас. Есть несколько ФС, решающих часть проблем (btrfs, например, или gfs), но они нестабильны просто или в плане скорости.
Мы храним в MongoDB файлы даже по 500кб. Есть нюансы, конечно, но как решение в целом на данный момент эффективность максимальная.
Последовательное чтение используется для парсера лога, например. Естественно, писать надо так, чтобы потом быстро читать. В MongoDB последовательная обработка тоже возможна, но есть нюансы.
Я не справочное бюро =) А так для линейного чтения в один поток по фигу, что за шедулер.
Не могу! Вы написали конечный объём в 50 терабайтов, за день это или за год, у меня данных нет. Но это всё равно про Линукс, написал уже два или три раза, что проблемы записи в Windows, используемом автором статьи.
Диск.
Об этом я написал в самом начале, вера опыт не заменяет. Скопируйте образ BR диска, например, и посмотрите, что будет с системой происходить. Чтобы два раза не вставать, советую смотреть счётчик Available для памяти в Task manager.
Про отключение writeback занятная теория (отключение WB, сюрприз!, не помогает), есть способ лучше =) O_DIRECT.
Это практика чего? Синтетического теста? У меня реальность другая, да. Чтения никогда не бывают без записей, такие нюансы придают бодрости на первой встрече с реальностью. Вы написали очевидный факт, непонятно зачем. Я утверждал исключительно о том, что readahead на сервере только вредит. В следующий раз, когда захотите блеснуть эрудицией, упомяните ещё промахи позиционирования головки, на современных дисках с ростом плотности актуальность всё больше.
Велик и могуч русский язык =) Увеличение задержки чтения и уменьшение количества прочитанных байтов есть замедление. Просто зависит от ситуации, что важнее.
Последовательное чтение мегабайтами используется для последовательной обработки данных. Не надо ничего переписывать. Вы рассуждаете про общие теории ни о чём. Я утверждаю, что когда может помочь readahead, он не имеет смысла. И утверждаю, что вы агитируете за использование магии, потому что нет опыта её применения. Ни один из ваших «советов» нельзя применить к опыту, описанному в статье, потому что опыт на Windows и говорить «а вот у меня в Линуксе много пишется и с памятью всё хорошо» демагогия.
Когда у нас индексы перестанут помещаться в память, всё встанет колом =) Тем не менее, ручным кэшированием обычно заниматься, ясное дело, неразумно.
Без деталей это данные ни о чём. Запросы к БД должны измеряться тысячами в секунду, обращения к просто файлам измеряться десятками килобайтов хотя бы (иначе зачем файлы?). Описанная вами ситуация ни рыба, ни мясо.
Невероятное знание! =)
IO-шедулер в серверной Убунте по умолчанию стоит десктопный, для единообразия. Дураков хватает везде. Тем не менее, я уважаю авторов Линукса, потому что в целом достойный результат.
Там был нюанс «в час». Либо вы в юношеском задоре пропустили этот нюанс, либо я сильно устарел и не в курсе, что уже можно писать по 15 гигабайтов в секунду на один сервер. Напомню ещё, что это было про Windows, который используется в обсуждаемом материале.
Зато была бы возможность осуществлять вызовы по сети, когда оно понадобится.
На практике, знаете ли, в здравом уме не читают последовательно блоками по 1 сектору, читают мегабайтами обычно. И пишут тоже. Есть нормальные понятные технологии, типа NCQ, чтобы ускорять доступ к диску. RA это магия.
Если какое-то приложение хорошо работает с RA, оно обычно работу с диском имеет третьестепенной важности — конфиг там прочитать или раз в час скинуть в журнал что-нибудь. То есть, ситуации, когда огромный относительный рост производительности выливается с смехотворные абсолютные значения.
В теории так, да =) Пока не столкнулся с этим, тоже так думал. В Linux свои «оптимизации», про доступную память при активной записи я говорил в Windows. В Task manager есть счётчик доступной памяти (Available), это чистые страницы или готовые в любой момент к возврату пользователю, грубо говоря, кэш чтения. Кэш записи просто так на диск не сбросить, особенно в контексте «поставить больше оперативки», когда скинуть на диск надо 90 гигабайтов. Free без разницы, какое значение имеет.
Конечно, я считаю, что это очень плохо, когда система всю свою оперативку использует под «грязные» страницы. Это плохо во всех отношениях, и пропадание питания чревато потерей очень большого количества данных, и доступной оперативки для приложений нет, и кэша чтения тоже нет.
Выглядело бы значительно ближе к реальности.