vob2014, ну етесссно. марафонцы же не сидят на таких диетах.
внезапно! мозг не только на сахаре работает:
оные диеты давно изучены в рамках борьбы с эпилепсией.
почему на них не сидят спортсмены, а один только Аткинс да Евген ? да потому что метаболизм углеводов больше энергии дает. подиетить можно, а вот совмещать с активными тренировками сложновато будет.
Так я бы с удовольствием.
Проблема с ПО в том, что оно взаимодействует с другим ПО и со временем перестает работать. Изменяется окружение, ОС, ядро и тд. Не так сильно меняются чтобы потребовалось с нуля переписывать программу, но работать перестает.
Кроме того, даже в неизменном окружении по мере более глубокого освоения продукта и знакомством с РАНЕЕ заявленными производителем возможностями, пользователь ПО постоянно находит баги внесенные давно, но не исправленные потому, что все силы брошены на новый продукт.
Позиция производителя тут бывает разная. В данном случае видно какая.
amigo5555, ну и что нам чужая жадность, уволенные разработчики и тд ? Мы смотрим на обещания: если написано, что лицензия вечная, то покупатель рассчитывает пользоваться ей вечно. По крайней мере, до полного изменения коньюктуры когда продукт вообще перестанет быть актуален.
Но тут не так.
А что с ней делать потом года через два, когда разработка опять зайдет в тупик?
вообще-то есть. специально запостил сюда самую суть.
Да что угодно. "Промышленная" разработка ПО не бывает простой. Никто из вендоров в принципе не может собрать в одном месте в тестовой лаборатории такое количество железа и пропустить действительно большой объем трафика. Они же железо продают, а не складируют.
Поэтому все будет делаться в авральном порядке и на коленке и неизвестное количество времени.
Именно поэтому вендоры продают услугу поддержки. Да еще и по стоимости такую же как железки. И весь крупный бизнес ее покупает. Так уж сложился рынок.
Безусловно, поставщик услуг тоже отчасти виноват и переводить стрелки на вендора тут не очень-то красиво : он может сам внимательно тестировать свои конфигурации и проводить нагрузочное тестирование еще до запуска в эксплуатацию. И консервативно подходить к вопросу обновлений - пусть конкуренты тестируют новые прошивки.
Но они этого не делают, потому как дорого.
А вы бы на месте даже старшего технического персонала делали бы ? Ведь зарплата от того, что будешь дополнительный месяц возиться с железкой больше не станет, а свалить на вендора всегда можно.
Кстати, еще к вопросу "западном" хостинге :
Так а кто сказал что они западные ? Почему вы так надеетесь на западный менталитет и основательность, но забыли что сейчас вся дешевая техподдержка - в Индии. Прошивки Сisco в Индии пишет. Вот и получите.
petr19, с правами root. вы можете начать выдумывать фокусы, но это уже не сотрудничество и работать с вами мало кто будет.
Если так уж важно, хотя бы не давайте доступ в личный кабинет на сайте провайдера, но даже там иногда возникает необходимость потыкать.
Ясно. Вам это не нужно.
Почему же текущую конфигурацию и уже замеченные узкие места не описали ?
Так-то гадать и теоретизировать можно очень долго.
Если mysql вытащить на отдельный том lvm, то такие программы как munin,atop,iostat покажут оценку загруженности очереди (Disk utilization) тома в процентах от 100. Начиная с каких-то версий ядра появились счетчики очереди не только на физические устройства, но и по томам. Только ядро нужно не очень старое. Можно ли этим цифрам доверять? Сам точно не знаю.
Если вообще все на LVM лежит, а части сайта разложены по отдельным томам, то можно сравнивать эти цифры друг с другом и делать вывод о относительной доли того или иного компонента в общей нагрузке на диск.
Для "среднестатистического веба" - один из самых выгодных вариантов. Не жрет mysql обычно много процессорного времени процессора. А вот большое количество простых и мелких запросов случается. Загрузку процессора вы легко оцените через top. Или лучше atop в режиме просмотра истории.
