astraliens

злодеи используют ваш тик для ддосов. режте все на 53 порт, что не из вашей сети

с радостью бы принял остался, я б забрал ??? увы, уже не остался... ожидаем прибытия...

с радостью бы принял

750GL - lan-->wan (pptp / pppoe в балансировке) в домашних условиях на 2 провайдера удается раскачать чуть больше 100 мбит (pps не смотрел, если честно) в сумме с 2 дырок, дальше процессор в потолок упирается, но не вешался ниразу

Когда админ ставит LFS в качестве ОС биллинговой системы, у него обязательно должно быть в столе, заявление по собственному желанию. Например 2008 r2? Вот это дикая ахинея. Пусть учатся. звучит печально..

ставте то, что умеет готовить ваш админ

а начиналось все с игрушечной затеи захостить сотню дружеских сайтов....

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

на хетзнере был тазик, не очень понравилосьКогда все под рукой так спокойней так есть ещё куча датацентров, хетзнер был лишь малым примером, тотже ovh или online.net из бюджетных вполне приемлемыми будут, погуглите, почитайте WHT или LET или же опять повторюсь - нормальаня виртуалка, коих как грязи выйдет дешевле и надежнее а спокойнее вам не будет, когда в очередной раз отключат свет часов на несколько иль любой другой катаклизм и ваши дорогие друзья уйдут в глубокий оффлайн, а если будет такое ещё и регулярно...не забыайте как они обрадуются падениям позиций в ПС из-за этого, не

не заморачивайтесь с кладовками, лучше арендуйте на том же хетзнере иль ещё где дедик и будет вам счастье... а то может с вашими сотней сайтами вам и нормальной виртуалки за 20-30$ хватит в плюс получите отличный аптайм и никакого головняка с "в соседнем подъезде свет отключили" или "жена в кладовке ведро воды разлила"..

писал вам утром в ПМ, ответте plz

посмотрите в сторону netsh батник с нужными параметрами запустить и создать соединение. может подойдет

это "относительно"...смотря что считать нормальным... железяки какие под все это добро стоят

это для myisam таблиц, а у вас innodb бъются у меня *.MYI у вас инно крашится, на что мускуль в логаз и жалуется 2014-08-01 14:00:30 916 [ERROR] InnoDB: Attempted to open a previously opened tablespace. Previous tablespace mysql/innodb_table_stats uses space ID: 1 at filepath: ./mysql/innodb_table_stats.ibd. Cannot open tablespace abills/admin_settings which uses space ID: 1 at filepath: ./abills/admin_settings.ibd 2014-08-01 14:00:30 28e01040 InnoDB: Operating system error number 2 in a file operation.

innodb_flush_log_at_trx_commit = 2 я выше предлагал значение этого пункта установить в 1 для большей надежности (упадет несколько производительность при этом) а можно ещё список железяк, на которых это добро вертится ps. skip-name-resolve skip-networking это в секции mysqld должно быть

это для myisam таблиц, а у вас innodb бъются

Ну в общем-то все не так и страшно, если кеш в памяти достаточно большой и большие лог-файлы (порядка часового объема записанных данных) - производительность весьма неплоха. Да, операция пишется сразу же в лог, но из лога в БД она попадает не сразу, а после группировки пачки изменений в транзакцию. В отличие от MyISAM. Итого - получается шустрее (MyISAM вроде как после каждого коммита же переписывает и индексы, т.е. - много iops мелкими блоками). длинные логи это само собой, но ещё ж есть целостность...внешние ключи.... медленно как ни крути, если не использовать транзакции или хотябы от

попробуйте тогда только --optimize --all-databases ps. сам конфиг и данные о железе на котором оно вертится можно с вашим экземпляром UPS ниразу в жизни не сталкивался, но судя по описанию оно умеет usb и rs232 - если нет драйверов готовых, то возможно есть где-то описание протокола, если удастся его на минимуме реализовать, чтоб обычным посылом данных в 232 получить данные об остатке заряда и раз в минуту кроном его дергать и в случае низкого заряда вызывать shutdown, а в биосе заставить мать находиться в состоянии always on - тогда после возобновления питания она автоматом заведется

как бы не хочется рисковать, сервер то боевой за исключением innodb_force_recovery все остальное не несет каких-либо проблем innodb-file-per-table - заставляет движок хранить данные в отдельных файлах ,а не в едином для инно innodb-flush-method = O_DIRECT - заставляет использовать другой метод сброса данных innodb_flush_log_at_trx_commit = 1 - управляет приоритетом сброса данных mysqlcheck - после рестарта сервера делать, оно сделает проверку и при надобности repair всех таблиц а так же optimize (что после установки innodb-file-per-table пересоздаст таблицы с инно и в

не может бедняга завестись из-за проблем в инно попробуйте добавить вот такие вещи в конфиг innodb-file-per-table = 1 innodb-flush-method = O_DIRECT innodb_flush_log_at_trx_commit = 1 потом перезапуститься и выполнить optimize и приведение в чувства всех таблиц mysqlcheck -u root -p --auto-repair --check --optimize --all-databases ещё можно попробовать на свой страх и риск поиграться с innodb_force_recovery = 1 или боле высоким значением, но тут нужно понимать в итоге что получаем

еще раз пересмотрел логи, НО ничего кроме: Can't connect to local MySQL server through socket '/tmp/mysql.sock' это приложение рапортует, а надобно глянуть в логи, что сам мускул пишет, там правду искать /var/log/mysql.log или mysql.err или куда они в my.cnf завернуты у вас На FreeBSD по умолчанию это файл /var/db/mysql/HOSTNAME.err где HOSTNAME - имя сервера (hostname). не заметил, что речь о фре идет, тогда да, в той стороне искать, спасиб за поправочку

еще раз пересмотрел логи, НО ничего кроме: Can't connect to local MySQL server through socket '/tmp/mysql.sock' это приложение рапортует, а надобно глянуть в логи, что сам мускул пишет, там правду искать /var/log/mysql.log или mysql.err или куда они в my.cnf завернуты у вас

а можно вопрос - что в логах пишет мускул отталкиваться нужно какраз от этого переход на innodb - хорошо, но готово ли ПО работать с инно innodb коммитит при вставке или обновлении каждую запись, что при большом объеме insert / update хорошенько подвесит процесс и нагнет диски (если заворачивать это в транзакции - то летать будет не хуже myisam), для перехода на инно сначала нужно, чтоб с ним адекватно ваше ПО работало, иначе получите ещё больше проблем, чем есть сейчас ну и потом тюнить его так, чтоб при падении терять минимум данных (привет innodb_flush_log_at_trx_commit и размеры буферо