То есть, в эти два слота вы ставили два одинаковых модуля памяти суммарно на 4 гб, спецификации которых точно поддерживаются материнской платой, процессор 64битный и все равно тормозило ?
чего скрывать-то? подробности пишите.
---------- Добавлено 07.08.2012 в 16:46 ---------- Пробовали NUMA отключить в ядре ? это нужно добавить параметр в загрузчике.
Всякое бывает. Например, несоответствие набивки памяти рекомендуемой производителем материнки - не в те слоты засунули или не добились двух- или трех- канальной конфигурации.
Подробнее опишите железо и в каких конфигурациях быстро, а в каких медленно.
Lodka, http://80.93.56.188/. Все, они уже побежали.
Dr.SEOMAG, ну вот о чем я и пишу : чтобы успешно пользоваться сервисами типа dns failover, нужно понимать что именно они делают.
Дубля сайта не получится. Единственное, что может случится, это поисковик где-то обнаружит ссылку на резервный IP http://12.34.56.78/, но в этом случае виртуальный хостинг обычно отдает затычку, а не ваш резервный сайт.
Lodka, никакая полупроводниковая электроника не может работать со скоростью света. Скорость передачи данных ограничена не столько скоростью непосредственно распространения сигнала по волокну, сколько скоростью переключения транзисторов. По крайней мере в географических масштабах европейской части России.
Плюс всевозможные синхронизации, буферизации, избыточность для коррекции и тд и тп всех уровнях передачи данных.
Любое промежуточное оборудование снижает скорость загрузки.
А еще VPS для балансировки не сможет обеспечить ту же скорость открытия сайта, какую обеспечивает хостинг сейчас. хоть на 50 мс, но точно медленнее будет. В качестве резерва еще можно потерпеть, а вот постоянно такое не понравится.
никак. написано же - хостинги не выделенные и не VPS:
К тому же, VPS для балансировки тоже может упасть.
Учитывая весьма свободные рамки, можно попробовать бекап по расписанию и сервисы dns failover. Например, вот этот http://www.dnsmadeeasy.com/services/dns-failover-system-monitoring/
И, конечно, надо понимать как именно это работает. Быть готовым к несогласованности и пропаданию части данных и тд.
А что в этом плохого ? Не понятно с какой целью этот пункт возник. Если не хотите усложнять автоматизацию, вполне можно убрать этот пункт.
В самой простой схеме любой, кто догадается подменить IP сайта на резервный, сможет зайти на сайт на резервном хостинге. Ну посмотрит устаревшую информацию и его изменения затрутся при следующем бекапе. Ну и что ?
если этот же сервер указан в /etc/resolv.conf, то есть, используется в качестве dns для программ запущенных на сервере, то надо оставить.
slaveofmoney, глупо тут только не приводить конкретных данных и не посчитать ресурс SSD. Вполне может даже выгодно оказаться.
И кстати, память вам не обязательно поможет. Дело в том, что СУБД страсть как любят фиксировать изменения на диск и это поведение является краеугольным камнем их надежности. И тут тоже нужно все посчитать прежде чем покупать.
Ну так логично же : купить 10 SSD дисков единовременно и убивать их каждый месяц.
Почему бы вместо слова "МНОГА", не озвучить конкретный объем записи в мегабайтах и числе операций в сутки ?
Весьма редкие классы задач могут убить современные SSD. Можно и попробовать собрать пилотный проект и посмотреть на тенденцию изменения ресурса SSD, который можно контролировать через SMART. Остальные варианты все равно дороже.
