Должно работать внутри OpenVZ. Вот ссылка
Значит я правильно вас понял. Инструкция как настраивать такие вещи здесь. Если не справитесь или будет нужна помощь - обращайтесь. Ставьте заявку и мы вам поможем.
Насколько я понял, вы хотите ходить в интернет через VPN ? Если я правильно вас понял, обращайтесь к нам, мы это настроим быстро и качественно. Для постановки задачи - зарегистрируйтесь в тикетной системе и оставьте заявку.
Привет,
Один из линков о подобной проблеме: http://kb.siteground.com/unroutable_address_bounced_back_message/
Но я думаю вы это уже видели... Если есть желание - можете обратиться к нам через тикетную систему, посмотрим.
Интересно понять какие именно пакеты теряются. Я полагаю что речь идет о TCP, при этом UDP, ICMP пакеты не теряются. Могли бы вы показать netstat -s ?
Здесь найдены интересные рассуждения по поводу iptables и потерянных пакетов.
Приведу цитату
"TCP allows the client to send a FIN packet, and you to ACK that FIN packet, but still keep your end of the connection open and push more data through it, sending your own FIN packet at some time in the future."
Иными словами, после посылки FIN пакета удаленной стороной, ваша система подтверждает разрыв TCP соединения через ACK, однако перед тем как послать FIN, некоторые время продолжает слать данные.
Вторая интересная ссылка по этой же теме здесь
Попробуйте запустить перловский скрипт повторно (нужно что бы база не перезагружалась как минимум часа 2-3, иначе он не может собрать статистику). После этого давайте попробуем выставить переменные в те значения, которые рекомендует скрипт. В данный момент (как вы видите из вывода скрипта), он дает такие рекомедации
Adjust your join queries to always utilize indexes Variables to adjust: sort_buffer_size (> 2M) read_rnd_buffer_size (> 8M) join_buffer_size (> 128.0K, or always use indexes with joins)
Как я написал выше, давайте подождем что бы база была запущена часа 2-3 и после этого выполним скрипт еще раз.
Я вижу в выводе медленных запросов квери, которые выполняются меньше секунды. Какой вы задали порог?
Давайте поставим 5 секунд и попробуем выловить самое "тяжелое ":
long_query_time = 4
Параллельно с этим, давайте прогоним скрипт для оптимизации MySQL. Вывод скрипта - в студию.
https://raw.github.com/major/MySQLTuner-perl/master/mysqltuner.pl
Что бы понять почему "тормозит" сайт, рекомендую воспользоваться одним из профайлеров. Например, newrelic. В базе данных рекомендую включить slow logs. Вывод медленных кверей может подсказать дальнейшие шаги.
Sasha Zerg, Мы тоже можем помочь. Отзывы о нашей работе здесь. Что бы поставить задачу, зарегистрируйтесь в тикетной системе. Подробнее тут. Качество гарантируем.
Как вариант, можно взять VPS за минимальную стоимость и настроить там OpenVPN.
