У вас есть цыпленок, точнее яйцо. Оно лежит в инкубаторе.
Неужели вы не осознаете, что чем чаще вы будете заглядывать в инкубатор, тем выше вероятность заметить что цыпленок уже вылупился.
Сильно буде отличаться вероятность?
Да нет никакой "специфической нагрузки" на память!!!!
Минимальный уровень ошибок, который наблюдает гугль,
происходит не при записи-чтении, а от природной радиации в основном.
А вот при модулях памяти с пониженным питанием, и шумом по питанию - ошибки будут выше этого _минимального_ уровня в десятки раз.
А вот когда ошибка _уже возникла_ - к чему она приведет зависит от специфики использования сервера.
Пруфлинк!!!!!!
Давай материалы о том что mysql _из коробки_ проверяет чексуммы данных в памяти, на случай битовых ошибок. Докажешь - плюсую. Не докажешь - минус, с подписью, как бесогонцу.
И надеюсь меня поддержат.
Вы тут бред полный пишете. Теорвер в вузе проходили... очень мимо.
По той сырой статистике 8% модулей серверной памяти выдавали ошибку хоть раз в год.
При 4-х модулях в машине вероятность получить за год ошибку - 50/50.
С учетом нонейма и десктопа - 100%.
Так вот если сервер у вас простаивает, и памяти свободной куча - есть вероятность что ошибка будет в не используемой области, либо что ошибка будет перезаписана и не приведет к фатальным последствиям... Тут уже вопрос нагружености сервера и специфики работы.
Однако одна ошибка в год на десктопе - практически гарантирована. А на "немного браке" - в разы больше. причем браке не только памяти, а psu или шимами в матери.
Причем вы можете считать что фатальные последствия это кернел паник, а я - что это битовая ошибка в БД, отправляющая на отгрузку не оплаченный реально заказ на 5000$.---------- Добавлено 31.03.2013 в 20:52 ----------
Как раз при такой загрузке - то, что у ксеона больше ядер, сыграет свою роль. И разница в скорости будет не более чем в 1,5 раз.
В условии вообще мало что было.
процессоры по скорости сравнимы.
i3 быстрее почти в 1,5 раза по общей мощности.
При этом у него 2 физических ядра, значит в однопоточном режиме он может дать
скорость до 3-х раз выше чем ксеон (выше удельная мощьность ядра).
Пример: если посетители изредка, и сервер не нагружен - геренация страниц будет быстрее до 3-х раз.
Также i3 более холодный, борцунам за экологию приятнее.
Однако отсутствие ECC - жирный минус.
Будьте морально готовы к тому что раз в год или чаще он будет зависать-перегружаться, может быть с повреждением FS и индексов БД.
Если вы готовы с этим оперативно бороться - выбирайте i3.
Если простои стоят дорого... скажем так если простой в 2 часа дает вам минус 50$ - берите ксеон без вариантов.---------- Добавлено 31.03.2013 в 20:23 ----------
Буду краток:
http://habrahabr.ru/post/171407/
Да, у Кита хорошая команда, попробуйте их VPS-ки, рекомендую.
А что именно это?
Если там 2 000 файликов - это не проблема.
А вот 100 000 - это повод отказать вашему аккаунту в резервном копировании.
Отказывать в самом хостинге - бред.
Очень может быть, что дело в паролях.
Но есть такой момент - если увели клиентский пароль, то заливался файл через ftp/scp/файлменеджер панели.
А это означает что в логах обязана фигурировать ip с которой было подключение.
И если хостер не может выдать внятных логов - значит либо не все так просто с
этим файлом, и в логах действительно ничего нет. Может быть сервер зарутили.....
Это случайно не centos ? с неделю назад был какой то смутный гвалт от любитеей
этого дистра.
Либо квалификация техподдержки ниже плинтуса, и она не может найти в логах очевидные вещи.
Вот и я говорю - при чем тут php?
Я говорю что в стандартном ядре нет возможности узнать точно кто и когда создал файл, и кроме того разрешен иногда chown и всегда touch. Пытаться совмещать временные отметки в пачке логов,
когда mtime файла подделан не особо перспективно.
===
Сначала сам php к вопросу приплел, потом мне же пишет "при чем здесь php".
Я несколько удивляюсь с этого разговора.
Да, функционал вшитый в php очень поможет узнать что файл был залит через scp.....
Скажем так - у меня на хостинге вы бы получили лог: процессом с каким Pid и именем, в какой момент и из под каких прав производилось изменение файла.
Ибо у меня используется достаточно сильно перепиленое ядро.
На страндартном ядре таких данных в лоб вы не получите, и если это взлом со стороны хостера - правду все равно не узнаете.
