- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

Что делать, если ваша email-рассылка попала в спам
10 распространенных причин и решений
Екатерина Ткаченко
Так вот в чему весь этот "гон"...
извините, не смог подобрать подходящего эпитета
Так вот в чему весь этот "гон"...
извините, не смог подобрать подходящего эпитета
Добрый день. Я заинтересовался методикой расчета и предложил ТС 2 сервера для проверки. А так же не нашел ничего ужасного в том, чтобы опубликовать результаты - так как это всего лишь железо, и оно у всех хостеров одинаковое.
Так же я не согласен с результатами теста и считаю, что синтетика не показывает реальной способности серверов выполнять те или иные задачи.
Мой ответ, который был дан ТС:
нет, не совпадают.
1) это не sas и не ssd - вполне закономерный результат. Скорость raid0 была бы выше, но я не вижу смысла собирать сата в raid0 - вероятность выхода такого массива из строя намного выше, а скорость при этом будет сопоставима с sas и ssd. raid1+0 это оптимальный вариант, позволяющи при выходе из строя одного диска
2) mysql ВСЕГДА необходимо оптимизировать. Любой конфиг из коробки никогда не покажет верха производительности. Нужно анализировать ситуацию на живой системе после нагрузки как минимум за 24 часа.
Выглядит это примерно вот так:
-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.1.66-0+squeeze1
[!!] Switch to 64-bit OS - MySQL cannot currently use all of your RAM
-------- Storage Engine Statistics -------------------------------------------
[--] Status: -Archive -BDB -Federated -InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 441M (Tables: 84)
[!!] Total fragmented tables: 21
-------- Performance Metrics -------------------------------------------------
[--] Up for: 112d 12h 40m 27s (34M q [3.577 qps], 1M conn, TX: 235B, RX: 5B)
[--] Reads / Writes: 95% / 5%
[--] Total buffers: 240.0M global + 16.7M per thread (151 max threads)
[!!] Allocating > 2GB RAM on 32-bit systems can cause system instability
[!!] Maximum possible memory usage: 2.7G (68% of installed RAM)
[OK] Slow queries: 0% (29/34M)
[OK] Highest usage of available connections: 25% (38/151)
[OK] Key buffer size / total MyISAM indexes: 192.0M/145.6M
[OK] Key buffer hit rate: 100.0% (2B cached / 97K reads)
[OK] Query cache efficiency: 79.6% (23M cached / 29M selects)
[!!] Query cache prunes per day: 42272
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 1M sorts)
[!!] Temporary tables created on disk: 48% (1M on disk / 2M total)
[OK] Thread cache hit rate: 99% (2K created / 1M connections)
[!!] Table cache hit rate: 9% (128 open / 1K opened)
[OK] Open file limit used: 22% (231/1K)
[OK] Table locks acquired immediately: 99% (8M immediate / 8M locks)
-------- Recommendations -----------------------------------------------------
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
Enable the slow query log to troubleshoot bad queries
When making adjustments, make tmp_table_size/max_heap_table_size equal
Reduce your SELECT DISTINCT queries without LIMIT clauses
Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
query_cache_size (> 24M)
tmp_table_size (> 24M)
max_heap_table_size (> 24M)
table_cache (> 128)
3) Сервер имеет два 6-ядерных процессора. При этом характеристики процессора занижены по сравнению с 4-х ядерными. Суть всего этого не в том, чтобы какое то одно задание отработало максимально быстро, а в том чтобы одновременно работало большее количество заданий.
К примеру одиночное задание будет работать быстрее на процессоре E3-1230 с тактовой 3.2Ghz на ядро, чем на E5-2620 с тактовой 2.0Ghz
Но если таких заданий запустить одновременно пару сотен, то E3 останется далеко позади.
[28.05.2013 15:39:50] coretek:vladimir.support: если битрикс нужен для работы с нагрузкой в 50-100 тысяч посетителей в сутки, то смысла брать E5 нет.
Если же ожидается 200-500 тысяч, тогда только двухпроцессорные системы.
[28.05.2013 15:40:56] coretek:vladimir.support: В идеале в любом случае всё очень сильно зависит от кеширования результатов выполнения скриптов. А оно в свою очередь зависит от количества оперативной памяти
[28.05.2013 15:41:53] coretek:vladimir.support: Можно допиливать сайт с упором на memcache, но вполне возможно что докупить еще 100 гигабайт ram будет дешевле, чем платить разработчикам за поиск узких мест и их устранение
[28.05.2013 15:42:36] coretek:vladimir.support: собственно как то так. синтетические тесты никогда не отражали реального положения дел
Не забрасывайте меня, пожалуйста, неспелыми помидорами - я не считаю себя специалистом в администрировании и тонкой настройке, а просто сообщил своё личное мнение.
Что то я совсем в ваших цитатах запутался, кто что и кому отвечал
вы забыли перелогиниться?
и про диски:
никогда не меряйте дискам скорость :) (что вообще за понятие такое по отношению к дискам?)
и никогда SATA 7.2к не будут быстрее ssd
(это в порядке ликбеза)
Что то я совсем в ваших цитатах запутался, кто что и кому отвечал
вы забыли перелогиниться?
и про диски:
никогда не меряйте дискам скорость :) (что вообще за понятие такое по отношению к дискам?)
и никогда SATA 7.2к не будут быстрее ssd
(это в порядке ликбеза)
Уточню - я есть сотрудник вышеназванной комании coretek.
Было предоставлено два конфига:
1) 2xE5-2620, 64gb ram, 4x2tb sata hdd, raid1+0 (логический массив 4тб), 100mbit
2) e3-1230, 8gb ram, 2x120gb sas, без рейда (фактически в тесте использовался один диск), 100mbit
По итогу вышло, что 2-й конфиг на тесте ТС работает ощутимо быстрее, чем первый. На основании этого я и изложил свои мысли - при высокой нагрузке отработают процессоры, а нехватка дисковой скорости может с лихвой компенсироваться переносом всего, что можно перенести, в оперативную память.
а нехватка дисковой скорости может с лихвой компенсироваться переносом всего, что можно перенести, в оперативную память.
Зачем заморачиваться? ТС на столько не соображает, что ему можно скормить сервер, загруженный с LiveCD, у которого все от корня ФС - в оперативной памяти ))))) Он даже не заметит :D Представляете, код пхп в памяти, все библиотеки тяжелые - там же, да еще и кэш опкода в памяти. Ну и рядом база данных тоже в память пишет ))
А, учитывая, что тесты ТС жарят в одно ядро, можно выключить гипер-тридинг и еще вдвое сделать быстрее сервер.
Тут резвиться можно как угодно. Делать сервера-ураганы из любого гавна на атоме.
Ща понтонусь, тут клиент как раз попался с битриксом.
Hetzner, ex10 + 250gb ssd.
собрал raid1 из двух дисков, на ssd положил базы (да, знаю, опасно,поэтому сделал бакап важных данных тут же с периодичностью), apc опять же... базы в innodb, nginx ....
на этом все. без каких либо наворотов и тюнинга...ну разве что в my.cnf написал query_cache_size=64M.
вывод - хецнер может, хецнер может, парам пам пам...! :) :)
Один из читателей этой темы смело предположил следующее
Зачем заморачиваться?
А, учитывая, что тесты ТС жарят в одно ядро, можно выключить гипер-тридинг и еще вдвое сделать быстрее сервер.
Тут резвиться можно как угодно. Делать сервера-ураганы из любого *авна на атоме.
По просьбе этого читателя, произведено тестирование физического выделенного сервера на CPU Intel Atom,
фрагмент вывода информации о протестированном сервере прилагается:
Финальное тестирование, производительность по внутреннему тесту:
Можно уверенно утверждать, что по параметрам быстродействия такой сервер явно уступает даже параметрам бесплатного хостинга ...
Один из читателей этой темы обратился с жалобой на работу старейшего московского хостинга,
его небольшой сайт при посещаемости всего 10 посетителей в сутки несколько раз в час
зависает при обращении к MySQL серверу хостинга
По просьбе этого читателя, произведено тестирование виртуального хостинга,
фрагмент вывода информации о протестированном сервере прилагается:
Финальное тестирование, производительность по внутреннему тесту:
По результатам замеров, читателю было предложено сменить хостинг.
Можно увидеть, что столь низкие показатели производительности не из-за конфигурации сервера,
так как почти аналогичный сервер занял первое место по производительности в категории SAS,
а исключительно благодаря настройкам хостинга ...
Ну раз мы пришли к выводу что всему виной не железо а конфигурация (о чем вам твердили всю тему), так какой смысл в теме вообще?
Приводить конфиги которые ничего не значат в тестах и не приводить конфигураций сервера (так как именно от них все зависит) это равным счетом не делать ничего.
Ну а то что вы здесь пишите это получился настоящий балаган, что и сами же подтвердили.
Один из читателей этой темы, предложил протестировать физический выделенный сервер,
с предустановленным пакетом ПО от известного питерского хостера.
На выбор хостер сразу предлагает 6 готовых к эксплуатации серверов.
Выбираем самый доступный тариф,
демо-сайт устанавливается практически моментально !
Тестируем конфигурацию, фрагмент вывода информации о протестированном сервере прилагается:
Финальное тестирование, производительность по внутреннему тесту,
без длительного тюнинга и каких-либо настроек,
практически моментально показывает почти 57 баллов ...
Еще раз делаю акцент читателей на таком моменте =
никаких настроек на сервере не производилось,
тестировалось то состояние сервера, в котором передавал его хостер своим клиентам !
Таким образом, физический выделенный сервер из Петербурга
занял сразу несколько мест в разных категориях нашего рейтинга хостингов:
По результатам экспресс-теста на
замере быстродействия файловой системы
при создании 1000 мелких текстовых файлов
данный сервер занимает третье место с параметрами:
По результатам экспресс-теста на
замере быстродействия при создании
таблиц в базе данных
данный сервер занимает первое место с параметрами:
Информация о хостере