ttttt

Например? Не могу вспомнить таких целей. Может раньше в офисах для какого-нибудь дибильного Active Directory виндоус и было легче, а сейчас оно зачем? Чтобы запустить софт, который не работает на линукс - не цель, это и так понятно.

Это не идеология, а чистая случайность. Полной независимости там и нет, соместимость гарантируется только через libc, как и во freebsd, кстати. В linux такого тоже хватает. Но да, с обратной совместимостью у него гораздо лучше, чем у freebsd. Скорее нет, чем да. Но может и повезет, если использование системы ограничено базовыми гну утилитами. С Win на серверах меньше "ипотни"? Впервые слышу.

Обязтельно в вакансии только фотка и: Но даже таких людей нет Поддержку Гайджина, явно прикол

А хз, нетмап для одного только хттп наверное не сильно и нужен. Просто под такую задачу можно было бы только доли процетов text/html ответов обрабатывать, а остальные пакеты тупо форвардить, получилось бы в 100 раз быстрее, чем с прокси.

4) с https не будет работать А вот на счет 3 - сейчас уже не так страшно. Раньше не было ничего готового, нужно было свой драйвер писать, в ядре копаться, а сейчас есть netmap и подобные, можно пару миллионов PPS в юзерленде на одной десктопной машине перемолоть.

А дальше смотреть в трафик, искать text/html ответы клиентам, буферизировать, парсить, вставлять свой html-код и отдавать свой ответ клиентам.

Что за зверь такой 500 ватт?

Хз, подозреваю, что хватит и часов 10 теста, надо посчитать. Мемтест же грузит память так, как никакая реальная система, может час мемтеста, как сутки какой-то приличной настоящей нагрузки.

В пределах одной СУБД, БД по сути всего-лишь нэймспэйс. Не исключено, что у кого-то может быть и разделение по БД где-то, не знаю у кого.

Кстати, а это смотря как посмотреть. Стоит ли оно того, если можно потестировать память и получить такие же или даже меньшие шансы любой ошибки, чем неисправимой с ECC? Чисто как способ узнать об ошибке - может быть в каких-то проектах и стоит, но я даже не представляю, что это за проекты должны быть. Там где с деньгами работа базе все равно никто не доверяет и данные пишутся еще в целую кучу мест. А там где не с деньгами редкие единчные ошибки сильно не нагадят, если вообще хоть как-то повлияют.

А вот и не вытеснит Все транзакции всегда глобально экслюзивные и ждут, пока не выполнится предыдущая, т.е. выполняются последовательно, так ACID требует.

В данном случае наихудшая - это однобитные исправления, т.е. как и обычное интеловское ECC. Почитайте все исследование, не выдирайте какие попало данные, они сами по себе ничего не значат. Вот же сказано, что у не чипкил в 4-10 больше неисправимых ошибок, ни о каких 0.1% вообще и речи не идет. У ошибок так же высокая корреляция, т.е. вероятность появления неисправимой ошибки в модуле после исправимой в тот же месяц (!) от 0.1% до 2.3%, в зависимости от чипкил это или примитивный. За год это уже каждый четвертый модуль у которого есть ошибки, особенно учтя, что ошибки либо постоян

Уже надоело об этом писать. Во-первых, как мы достаем ячейку таблицы? Мы смотрим в индексе, где на диске она находится, достаем блок и выдираем оттуда ячейку. Нет никакого отдельного интерфейса для доставания блоков из памяти, мы всегда как-будто достаем его с диска. Эта функция внутри дергает диск и подгружает блок в память, если в памяти блока нет и затем проверяет контрольную сумму блока и либо ошибка либо блок возвращается. И абсолютно все равно, если блок будет вытеснен из кэша процессора, строка прочитана и дальше она не нужна.А длительные запросы не длительные от балды, они что-то делаю

В это и суть, что оказывается ошибки из-за брака, а не заряженных частиц и т.д.

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

0.22%, если быть точнее. Но гугл там же пишет. что очень большой разброс, у chipkill модулей получше, у более примитивных уже аж 1% неисправимых ошибок. Нет, не т.е.. У 80% модулей никогда не появляются ошибки, независимо от их времени использования, температуры и т.д. А 20% модулей виноваты почти во всех ошибках. Это значит, что для машин с 4 модулями и примитивным ECC шансы уже аж под 80% наткнуться на битый модуль. И в каждой 5-й такой машине на много неисправимых ошибки, не 1-а в год, а уже аж 1-а в неделю.

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

Не считаю. По сети запросы обычно шифруются, будет битый - не расшифруется. Типичная реализация кэша - LRU кэш блоков файлов, вместо чтения из файлов с диска блоки читаются из памяти вместе с CRC суммой и проверяются, а если в памяти нет, то с диска и ложатся в кэш. Проверяются блоки либо всегда, либо опционально, зависит от движка и его гарантий. Для хороших ECC (не таких, как у интела сейчас) можно же и отключить проверку, может производительнось кому-то очень важна. Вытеснение в данном случае ни на что не влияет. Есть кэши на других уровнях, типа кэш запросов, он наверное и не проверяется,

Сеть ipv6 это ж вообще не проблема для предприятий. Основные затраты предприятий - это софт, который не умеет ipv6, т.е. почти весь.

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

35162.pdf Близко к истине, но они такие же и для ECC памяти. По данным гугла 20% модулей виноваты в от 94% до 99.6% всех ошибок, а основная масса модулей вообще не видит ошибок. P.S. Могу пересказать коротко исследование гугла, если кому-то на английском тяжело читать

Ничего не делать, удалить из кэша и вернуть ошибку. Данные можно восстановить с другого сервера ручками или автоматически, если архитектура позволяет. В этом же суть БД с гарантированной согласованностью, чуть что - ошибка. Почему соответственно? Это теоретичски на двух несвязанных битиках одновременно, а на связанных может будет даже тот же порядок. UPD: Кстати, по данным гугла 0.22% модулей (и аж 1% для 4 GB DDR2) получают хоть одну неисправимую ошибку в год (т.е. 2 бита в одной строке и больше) и до 2-4% машин в год в зависимости от платформы у них же. Это очень много. В том,

БД должна считать суммы, чтобы гарантровать согласованность, как раз чтобы не было такого, что поврежденные данные из кэша использовались для чего-то, сумма считается перез использованием. В случае несовпадения считать строку негодной и возвращать ошибку, чтобы транзакцию можно было отменить. По дефолту в мускуле myisam движок, который ничего вообще не гаратирует и никаких транзакций не поддерживает. Он и годится только для каких-нибудь форумов, где не так страшно битые данные Когда данные поднимаются с диска - они поднимаются блоками, т.е. вместе с контрольной суммой и ложатся в кэш

А что за БД такая, что контрольные суммы не считает? По ACID обязаны, т.к. ECC особенно ничего не гарантирует, ну там если испортится 1 бит из 64 - исправит, а два уже нет и может даже не отдетектить.

Хз, если предупредить и открывать порт, кому нужно, то наверное и не попадает.