ttttt
-
Всього повідомлень
2 081 -
Приєднався
-
Останній візит
-
Дней в лидерах
14
Тип контенту
Профили
Форум
Календарь
Все, що було написано ttttt
-
Например? Не могу вспомнить таких целей. Может раньше в офисах для какого-нибудь дибильного Active Directory виндоус и было легче, а сейчас оно зачем? Чтобы запустить софт, который не работает на линукс - не цель, это и так понятно.
-
Это не идеология, а чистая случайность. Полной независимости там и нет, соместимость гарантируется только через libc, как и во freebsd, кстати. В linux такого тоже хватает. Но да, с обратной совместимостью у него гораздо лучше, чем у freebsd. Скорее нет, чем да. Но может и повезет, если использование системы ограничено базовыми гну утилитами. С Win на серверах меньше "ипотни"? Впервые слышу.
-
Компания ищет специалиста. Перепост.
тема ответил в Melanxolik пользователя ttttt в Наш флейм про мережі
Обязтельно в вакансии только фотка и: Но даже таких людей нет Поддержку Гайджина, явно прикол -
А хз, нетмап для одного только хттп наверное не сильно и нужен. Просто под такую задачу можно было бы только доли процетов text/html ответов обрабатывать, а остальные пакеты тупо форвардить, получилось бы в 100 раз быстрее, чем с прокси.
-
4) с https не будет работать А вот на счет 3 - сейчас уже не так страшно. Раньше не было ничего готового, нужно было свой драйвер писать, в ядре копаться, а сейчас есть netmap и подобные, можно пару миллионов PPS в юзерленде на одной десктопной машине перемолоть.
-
А дальше смотреть в трафик, искать text/html ответы клиентам, буферизировать, парсить, вставлять свой html-код и отдавать свой ответ клиентам.
-
Нужен выделенный сервер.
тема ответил в Serhiyyy пользователя ttttt в Датацентри. Хостінг. Colocation.
Что за зверь такой 500 ватт? -
Хз, подозреваю, что хватит и часов 10 теста, надо посчитать. Мемтест же грузит память так, как никакая реальная система, может час мемтеста, как сутки какой-то приличной настоящей нагрузки.
-
В пределах одной СУБД, БД по сути всего-лишь нэймспэйс. Не исключено, что у кого-то может быть и разделение по БД где-то, не знаю у кого.
-
Кстати, а это смотря как посмотреть. Стоит ли оно того, если можно потестировать память и получить такие же или даже меньшие шансы любой ошибки, чем неисправимой с ECC? Чисто как способ узнать об ошибке - может быть в каких-то проектах и стоит, но я даже не представляю, что это за проекты должны быть. Там где с деньгами работа базе все равно никто не доверяет и данные пишутся еще в целую кучу мест. А там где не с деньгами редкие единчные ошибки сильно не нагадят, если вообще хоть как-то повлияют.
-
А вот и не вытеснит Все транзакции всегда глобально экслюзивные и ждут, пока не выполнится предыдущая, т.е. выполняются последовательно, так ACID требует.
-
В данном случае наихудшая - это однобитные исправления, т.е. как и обычное интеловское ECC. Почитайте все исследование, не выдирайте какие попало данные, они сами по себе ничего не значат. Вот же сказано, что у не чипкил в 4-10 больше неисправимых ошибок, ни о каких 0.1% вообще и речи не идет. У ошибок так же высокая корреляция, т.е. вероятность появления неисправимой ошибки в модуле после исправимой в тот же месяц (!) от 0.1% до 2.3%, в зависимости от чипкил это или примитивный. За год это уже каждый четвертый модуль у которого есть ошибки, особенно учтя, что ошибки либо постоянные либо нет. (Кстати у гугла нет данных по модулям с больше одной неисправимой ошибкой, они такие модули при первой такой ошибке и заменяют) Вот еще такой момент, количество ошибок сильно связано с использованием памяти. Что и так очевидно, раз ошибки хардверные. Но что означает для нас, что какой-то типичный веб-сервер с домашними страничками даже с битой памятью не будет видеть ошибки очень долго и о браке можно узнать по сути только мемтестом. Потому что она либо отправляется, как ответ на запрос, либо ложится во временную таблицу (например для JOINов). Принципиально нет ничего невозможного, но БД, как и ОС требуют настройки, чтобы чего-то гарантировать.
-
Уже надоело об этом писать. Во-первых, как мы достаем ячейку таблицы? Мы смотрим в индексе, где на диске она находится, достаем блок и выдираем оттуда ячейку. Нет никакого отдельного интерфейса для доставания блоков из памяти, мы всегда как-будто достаем его с диска. Эта функция внутри дергает диск и подгружает блок в память, если в памяти блока нет и затем проверяет контрольную сумму блока и либо ошибка либо блок возвращается. И абсолютно все равно, если блок будет вытеснен из кэша процессора, строка прочитана и дальше она не нужна.А длительные запросы не длительные от балды, они что-то делают последовательно, например собирают данные из разных ячеек и ложат их во временную таблицу, которая таким же образом читается/пишется блоками с контрольными суммами. А если нужно посчитать что-то, например общий возраст пользователей, то он из кэша не будет вытесняться, потому что будет дергаться после чтения каждого блока. Я глянул по подсказке кайота, у интела есть аналог чипкила, SDDC, но не у дешевых серверных платформ и не у новых почему-то. Не так, "хотя бы 1 ошибку в год" это точно так же, часть модулей не видят неисправимые ошибки, а часть видит много и часто. Т.е. скажем у меньшей части модулей с ошибками будет прилично неисправимых ошибок каждую неделю/месяц. Не важно в общем, реальных гарантий это 1-битное исправление не дает. Нет, я на глаз прикинул, не надо придираться. Нужно сначала посчитать вероятность, что все одновременно целые 0.8**4 и оставшаяся будет вероятность, что хоть одна битая 1 - 0.8**4 = 0,6, т.е. 60%, а не 80%. Сори, что число из головы не подошло А для 8-ми модулей будет 1-0.8**8 = 0.83
-
В это и суть, что оказывается ошибки из-за брака, а не заряженных частиц и т.д.
-
Лично мне это исследование гугла говорит о том, что если есть возможность тестировать память, то лучше брать обычную память и пару дней тестировать, если не будет ошибок, то их уже и никогда не будет. Можно ощутимо сэкономить на обычном железе, а то ECC только на серверных платформах включено, хоть оно и в процессорах теперь.
-
0.22%, если быть точнее. Но гугл там же пишет. что очень большой разброс, у chipkill модулей получше, у более примитивных уже аж 1% неисправимых ошибок. Нет, не т.е.. У 80% модулей никогда не появляются ошибки, независимо от их времени использования, температуры и т.д. А 20% модулей виноваты почти во всех ошибках. Это значит, что для машин с 4 модулями и примитивным ECC шансы уже аж под 80% наткнуться на битый модуль. И в каждой 5-й такой машине на много неисправимых ошибки, не 1-а в год, а уже аж 1-а в неделю.
-
Не считается, блочный кэш не на том уровне, он используется, как будто кэша вообще не существует. Вот нам надо прибавить число к каким-то записям, они читаются, как-будто с диска, и прозрачно проверяются, если два раза читаются, два раза проверяються. Распаковали запись, прибавили число (все это в кэше процессора) - пишем в лог на диск с CRC для записи, блока или другим способом. Конечно, данных может много, тогда создаются временные таблицы, они ничем не отличаются от обычных, ну кроме в лог не пишутся, и точно так же при каждом обращении проверяются CRC для блоков. Т.е. теоретически может быть ситуация, когда распакованные данные успели вытесниться в память, например kill -STOP в очень удачный момент, загадить кэш процессора после этого, но это только теоретически. Как по мне ECC память позволяет только узнать, какую планку нужно менять и это единственный ее плюс. Если бы интел реально пытались ошибки исправлять, то там бы было что-то не такое примитивное, а хотя бы как у chipkill. А так они даже не пытаются и как оказывается шансы неисправимой ошибки всего в десяток раз ниже, чем исправимой, зачем кому-то такая недокоррекция? (следуя данным гугла получается 2 из 10 битых модулей будут выдавать очень много неисправимых ошибок)
-
Не считаю. По сети запросы обычно шифруются, будет битый - не расшифруется. Типичная реализация кэша - LRU кэш блоков файлов, вместо чтения из файлов с диска блоки читаются из памяти вместе с CRC суммой и проверяются, а если в памяти нет, то с диска и ложатся в кэш. Проверяются блоки либо всегда, либо опционально, зависит от движка и его гарантий. Для хороших ECC (не таких, как у интела сейчас) можно же и отключить проверку, может производительнось кому-то очень важна. Вытеснение в данном случае ни на что не влияет. Есть кэши на других уровнях, типа кэш запросов, он наверное и не проверяется, если включите, то конечно никаких реальных гарантий не получите. А вообще CRC там много где еще, и в репликации, и даже для ответов по сети могут считаться, если соединения не шифруются (в том же mysql cluster). Все зависит от ваших задач. Иногда даже БД нельзя доверять и какой-нибудь SHA1 самому еще раз для каждой строки считать.
-
Сеть ipv6 это ж вообще не проблема для предприятий. Основные затраты предприятий - это софт, который не умеет ipv6, т.е. почти весь.
-
Ну да, теоретически нельзя. Но тут такой момент, когда посчитали контрольную сумму блока - данные уже не в памяти, а в кэше процессора и пока с ними идет работа в память за ними больше лезть не надо. Если кэш процессора глючный - то контрольная сумма не прошла бы или даже машина не загрузилась бы Шансы, что и прошла бы контрольная сумма и кэш был был бы глючный настолько маленькие, что ими можно просто пренебречь, есть куда более серьезные проблемы, от которых нельзя спастить.
-
35162.pdf Близко к истине, но они такие же и для ECC памяти. По данным гугла 20% модулей виноваты в от 94% до 99.6% всех ошибок, а основная масса модулей вообще не видит ошибок. P.S. Могу пересказать коротко исследование гугла, если кому-то на английском тяжело читать
-
Ничего не делать, удалить из кэша и вернуть ошибку. Данные можно восстановить с другого сервера ручками или автоматически, если архитектура позволяет. В этом же суть БД с гарантированной согласованностью, чуть что - ошибка. Почему соответственно? Это теоретичски на двух несвязанных битиках одновременно, а на связанных может будет даже тот же порядок. UPD: Кстати, по данным гугла 0.22% модулей (и аж 1% для 4 GB DDR2) получают хоть одну неисправимую ошибку в год (т.е. 2 бита в одной строке и больше) и до 2-4% машин в год в зависимости от платформы у них же. Это очень много. В том, что БД не полагаются на железо для гарантий, которые они дают, ECC им ничего не даст.
-
БД должна считать суммы, чтобы гарантровать согласованность, как раз чтобы не было такого, что поврежденные данные из кэша использовались для чего-то, сумма считается перез использованием. В случае несовпадения считать строку негодной и возвращать ошибку, чтобы транзакцию можно было отменить. По дефолту в мускуле myisam движок, который ничего вообще не гаратирует и никаких транзакций не поддерживает. Он и годится только для каких-нибудь форумов, где не так страшно битые данные Когда данные поднимаются с диска - они поднимаются блоками, т.е. вместе с контрольной суммой и ложатся в кэш вместе с ней. Перед любым использованием контрольная сумма проверяется. Если данные хоть в памяти, хоть на диске будут запорчены - проверка контрольной суммы не пройдет и транзакцию можно будет отменить. Лучше посчитайте вероятность сбоя в 24 гиговом модуле с ECC за год работы, а потом посчитайте если таких машин 10 или 100. Окажется, что гарантии ЕСС не такие уж и высокие, даже у одного большого тазика за долгую работу данные могут попортиться. И реально ЕСС не дает приложениям увидеть отдетектинную ошибку, так что либо исправляет один бит, либо ничего.
-
А что за БД такая, что контрольные суммы не считает? По ACID обязаны, т.к. ECC особенно ничего не гарантирует, ну там если испортится 1 бит из 64 - исправит, а два уже нет и может даже не отдетектить.
-
Можно ли закрыть доступ к некоторым сайтам ?
тема ответил в Windows пользователя ttttt в Наш флейм про мережі
Хз, если предупредить и открывать порт, кому нужно, то наверное и не попадает.