:) ну тогда колитесь, сколько у Вас на VPS влазит на сервер и какой конфигурации сервер с VPS-ами
- а чего тут деликатничать? Все довольно прозрачно - вот например хостер обещает 8% CPU от "ресурсы CPU указаны в процентах от общей вычислительной мощности сервера класса Dual Intel Xeon 3.0GHz". Предположим что на сервере стоит два четырехядерных ксеона (наиболее вероятный случай), а хостер хитрый (тоже весьма вероятно) и считает проценты от ядра (а не от процессора), таким образом у нас выходит примерно 12,5 аккаунтов на ядро или 100 аккаунтов на сервер. Проверимся по расходу ОП - тот же хостер гарантированно дает на том же тарифе 384Мб ОП, для 100 аккаунтов (при отсутствии оверселла, а то вдруг хостер особо хитрый) выходит 38Гб ОП (округлим до 40Гб), поделим на размер планки 4Гб, выходит 10 планок по 4Гб. Возможно ли такое? Вроде да, хотя более реальной представляется 6 планок по 4 Гб, т. е. 24Гб ОП, что при отсутствии оверселла и выделении 384Мб на аккаунт, дает цифру 64 аккаунта (что хорошо коррелируется с соответствующей маской подсети).
- вывод: на типичном сервере (бывают и нетипичные монстры) можно разместить около 60-90 типичных VPS аккаунтов (в смысле, с разумным выделением ОП и ЦПУ)
- Вы можете сказать хостеру, что он должен настроить MySQL таким образом чтобы подвисшие соединения закрывались автоматически (настройка wait_timeout). Лучше поменяйте хостинг прямо сейчас - у Вас явно какой-то школьный хостинг, проблемы с которым будут продолжаться.
- в порядке рекламы: возьмите у нас тестовый хостинг (1 месяц бесплатно) на любом тарифе с БД и посмотрите возникнет ли описанная Вами проблема (установить сайт поможем)
Не заметил:
- надо более подробно расписать ТЗ, в виде доступном для понимания web-разработчикам.
Например:
Прикладная строительная энциклопедия - статьи добавляемые через админку (дальше по пунктам - статьи с картинками? иерархически группируемые?)
Лента новостей строительного рынка - новости добавляемые через админку (с картинками? с анонсами на главной странице? в формате RSS?)
и т. д.
Чем больше конкретики в ТЗ, тем точнее оценка объема работ и тем точнее оценка их стоимости.
- как написал T.R.O.N - на самописанном дыижке 3-5тыс$ (возможно от 2тыс$ если перевести фразы типа "Площадка сертифицированных рабочих" на доступный для понимания язык - "Каталог текстовых резюме")
- где в ТЗ хоть слово про дизайн? (может заказчику все надо делать на флэше) Все пожелания клиента должны быть отражены в ТЗ - в противном случае все кончится плохо (заказчик не получит то что он хотел, разработчик не получит части денег). В нормальных web-студиях с заказчиком проводят долгую беседу, на основе которой составляют черновое ТЗ, которое затем представляют заказчику и опять беседуют на предмет понял ли он что написано в ТЗ, со всем ли согласен и т. д., затем делают окончательное ТЗ которое дают заказчику на утверждение и только после утверждения начинают работу над дизайном и программной частью.
- у нас на тарифах типа "Большой" eAccelerator уже стоит, на VPS тоже. На Большом месяц бесплатного теста - обращайтесь, смотрите что выйдет :) Прошу прощения за невольную рекламу - не смог удержаться :)
- ну половина это преувеличение, но факт, проблемы изредка бывают :(
- ЦПУ используется и в сетевых операциях, и при работе с жестким диском, и в web-сервере, который будет обрабатывать запросы клиентов, так что нагрузка на ЦПУ при увеличении количества закачек будет однозначно расти.
- а хрен его знает :) во первых неизвестно как хостер учитывает загрузку ЦПУ, во вторых неизвестно как устроена его дисковая подсистема (Soft RAID, Hard RAID, сетевая файловая система и т. п.) и т. д.
Забыл добавить, что еще неизвестно о каком CPU идет речь: одно дело 1% от двух четырехядерных Xeon-ов, а другое дело 1% от Celeron-а :)
Попробуем порассуждать: при выполнении запроса БД периодически (не всегда!) сообщает "Can't create/write to file '/tmp/#sql_1db0_0.MYD' (Errcode: 17)", что дословно (для тех кто видит разницу между 17 и 28) означает что запись невозможна, так как файл с именем #sql_1db0_0.MYD уже существует. ОК - хостер чистит папку /tmp (удаляет злополучный #sql_1db0_0.MYD) и все снова работает до следующего сбоя. Теперь вопрос - а из-за чего происходит сбой? Почему MySQL создает файл #sql_1db0_0.MYD, а потом не может его удалить и он остается в папке /tmp? Одно из разумных предположений что этот временный файл был успешно создан, затем по каким-то причинам, переполнился /tmp, произошел сбой в результате которого #sql_1db0_0.MYD не был удален по завершении запроса, ну а дальше netwind тычет нас в код ошибки и говорит что эта ошибка означает что файл уже существует :)
Менее вероятный механизм возникновения описанной ошибки описан тут и в документации - в настройках MySQL отсутствует путь к папке для временных файлов, мелкие запросы выполняются в ОП, а запросы не влезающие в ОП требуют записи во временную директорию которой по умолчанию считается /tmp, а у этого /tmp нет прав для записи от имени пользователя под которым работает MySQL.
Думаю не только мне интересно как зовут хостера :)
- внимательней читайте сообщения которые приводят клиенты, а то не дай бог не найдете с ними общего языка :
- одно другому не мешает: Can't create/write to file, но суть скорее всего одна - не хватает места для временных файлов в папке /tmp
- это Вы откуда узнали? :)
- если сервер MySQL используется многими пользователями, то запросто
