Alexey27, а вы уже в курсе, что размещение WOW неофициального на территории многих стран будет преследоваться по закону, а размещение сервера в Китае будет чревато пингами от 500 ms ?:) Или сервер и капец ... :) трава не рости :D
Стоимость выделенного канала 100 MB/s будет колебаться от 1$ до 5$ за 1 MB/s соответственно 100-500$ канал + аренда оборудования, скажем баксов 100$ сверху... приблизительно такие ценники встретите .....
WapGraf, там уже пару раз TOP мелькал ))) если бы что-то было весомое оно было бы "сверху" ))) так что полагаю там LAMP + FTP и ничего более , ну может панель какая-то еще>.. :) никаких томкетов и прочего ядерно жрущего не видать :D
А сколько вы считаете по сравнению с остальным окружением должен кушать SQL при условии что у нас вебсервер + фтп + mysql ? 500 MB ? Я отдаю в таких случаях по 70-80% памяти , собственно как и ТС, никакой проблемы в этом не вижу, другие демоны на недостачи памяти не жалуются...
Конечно может, ровно как и из за любого другого демона....
Судя по df -h у вас не смонтирован shm ? Перенесите временные таблицы в SHM, чуток отпустит MySQL , но надо будет памяти IMHO в тазик добавить чуток.... Ибо там по TOP вашему виднеется 200 MB в свопе .... Стало быть ..... мало памяти?
Чертовски классная формула, но не понимаю чем она помогает \ мешает в данном случае, у него же и при 150 коннектах максимальная память в приделах нормы.... то что завышено число коннектов и как следствие выделяется избыточное количество памяти под буфера - это конечно плохо, но мало вероятно что это хоть как-то отражается на проблеме которая существует.---------- Добавлено 07.05.2013 в 16:52 ----------
Вот вот, я о том же.... сильно мало там движения что бы создавать какие-то проблемы.... ))) у меня maxmem например при текущих настройках будет в районе 20-25 GB ... :))) У ТС-а вообще 2 гига памяти, что там ворочать можно то... тут что-то более интересное, я пока склонен полагать что или аппаратные приколы с сетевкой и таки бочинит TCP/IP ну или магия :D
Нет, просто полагаю, что консистенцию проверять это одно дело, а копировать данные с винта на винт другое... не более того, процесс чека в любом случае должен топать быстрее процесса синка... хотя бы по тому, что там чтение , а там запись.... может оно конечно и не в 24 раза, но обращал внимание у себя на центосах, если случился вдруг холодный ребут ... это ребилд рейда как полагается, а при длительном аптайме проходит чек который завершается в раз быстрее, но это только наблюдения, замеров точных не делал, может быть там разницы и пару часов.... Подождем пока ТС проснется и напишет сколько там уже :D
Ну т.е запись никак не медленней чем просто чтение ? :) Я имел ввиду что реконструкция под нагрузкой может занять например 2е суток как писало там выше, а обычный check проскочит за пару часов..... если там конечно нарушений структуру не будет серьезных и не придется таки в режим sync переходить :)
хммм.... простите в чем же тогда разница? :)
/usr/share/mdadm/checkarray -x --all
Ага, сразу не придал этому значения, кстати "check" должен как бы быстрее топать нежели "sync" , а то там 2 дня написано ждать :D
Я предлагаю попробовать, так как не ясно какие могут быть оборванные коннекты при работе с локальной тачкой ?:)
Ну особенность известная..... в соответствующих кругах... :D :D
