|
|
|
 
C нами с 10.05.2006
Репутация: 14.8  
|
|
|
Господа, а что вы думаете по поводу кластерной архитектуры на базе обычных компьютеров - она проигрывает по производительности одному серверу (конфиг которого неоднократно мелькал в теме)?
|
|
|
|
|
|
|
 |
|
|
|
Возраст: 36  
C нами с 22.01.2006
Репутация: 256.8
|
|
|
NeXxT, место и электроэнергия... Для таких масштабов она не очень эффективна...
|
|
|
|
|
|
|
|
|
|
|
Возраст: 39 
C нами с 04.05.2006
Репутация: 63.9
|
|
Господа администраторы, а можно ли получить статистику работы системы, как можно детальнее (кол-во HTTP запросов в сек., SQL запросов в сек. итп)?
Просто разговор ниочем получается.
Мне кажется, что проблемы в самом форуме, и в том что он не рассчитан на такую нагрузку. Это только мое предположение, так что просьба сильно не пинать  .
Предложение: разнести сервер БД и Веб-сервер на разные машины. Выигрышь в производительности должен быть...
|
|
|
|
|
|
|
|
|
|
|
Возраст: 57
C нами с 08.03.2005
Репутация: 95
|
|
| Petro писал(а): |
Господа администраторы, а можно ли получить статистику работы системы, как можно детальнее (кол-во HTTP запросов в сек., SQL запросов в сек. итп)?
Просто разговор ниочем получается.
|
поддерживаю.
По поводу разнесения БД и Веба на разные машины:
Настоятельно рекомендую это сделать. Причём для БД подойдёт любой 2-х ядерный процессор даже Pentium D 925 база данных не сможет загрузить на полную катушку - производительность всё равно упрётся в дисковую подсистему.
А для хранения наиболее часто используемых таблиц БД советую прикупить http://www.ixbt.com/storage/gigabyte-iram-p1.shtml дёшево и сердито.
|
|
|
|
|
|
|
|
|
|
|
Возраст: 36
C нами с 22.01.2006
Репутация: 256.8
|
|
По поводу разноса - всё так и планируется. Только вот исходя из опыта по базу данных надо наоборот более производительную машину. В диски ничего не упрется, если памяти будет много. В крайнем случае кину базу на рам диск.
P.S. Athlon 64X2 3800+ база спокойно в одиночку загружает...
Добавлено спустя 1 минуту 32 секунды:
Количество запросов при полной нагрузке вечером посмотрю - точно не помню.
|
|
|
|
|
|
|
|
|
|
|
Возраст: 39
C нами с 04.05.2006
Репутация: 63.9
|
|
| splav писал(а): |
|
Только вот исходя из опыта по базу данных надо наоборот более производительную машину.
|
Так и нада! 
|
|
|
|
|
|
|
|
|
|
|
Возраст: 36
C нами с 22.01.2006
Репутация: 256.8
|
|
|
Petro, это я к комментарию zelen.
|
|
|
|
|
|
|
|
|
|
|
Возраст: 39
C нами с 30.09.2004
Репутация: 102.4
|
|
Меня убивают просто показатели "колличество SQL запросов в секунду" и "колличество HTTP запросов в секунду"
1. Как можно сравнивать запрос SELECT xname, xdata FROM xtable WHERE id = 4365, где id - PRIMARY KEY. Пусть хоть в этой таблице миллион строк. Сравнивать с запросами по выводу списка блогов, с присоединенными к ним таблицами с записями блогов, пользователями, какиминибудь сессиями, "настроениями" и т.п. Во время выполнения второго запросы успет выполниться тысяча первых.
2. Вот такой вот файл http://unsorted.ru/images/smiles/yellowgrinx.gif web-сервер можно отдать где-нибудь тысяч эдак раз 5, в то время пока обрабатывается всего ОДИН запрос к weblogs.php, например.
АБСУРДНЫЕ ПОКАЗАТЕЛИ!
|
|
|
|
|
|
|
|
|
|
|
Возраст: 39
C нами с 04.05.2006
Репутация: 63.9
|
|
iZz, и в чем же, интресно, здесь обсурд?
В чем же тогда оценивать нагрузку на сервер и производительность сайта? Можно конешно в крокодилах, но вот как-то пока не научился... 
И дело совсем не в сложности запросов, а в их количестве(при оценки производительности САЙТА, а не сервера!)...
|
|
|
|
|
|
|
|
|
|
|
Возраст: 36
C нами с 22.01.2006
Репутация: 256.8
|
|
Petro, могу сказать что в данный момент апач(он обрабатывает только php) выглядит так:
CPU Usage: u197.88 s34.73 cu10.2 cs0 - .249% CPU load
5.31 requests/sec - 172.7 kB/second - 32.6 kB/request
53 requests currently being processed, 0 idle workers |
База данных:
MySQL on localhost (4.1.22) up 2+04:25:35 [21:04:51]
Queries: 55.3M qps: 307 Slow: 105.3k Se/In/Up/De(%): 79/00/08/01
qps now: 327 Slow qps: 3.5 Threads: 68 ( 57/ 134) 62/02/11/03
Cache Hits: 30.4M Hits/s: 168.8 Hits now: 64.7 Ratio: 69.5% Ratio now: 32.2%
Key Efficiency: 100.0% Bps in/out: 49.4k/ 3.4M Now in/out: 60.9k/569.8k
|
Добавлено спустя 2 минуты 14 секунд:
А поп поводу оценки - позвольте не согласиться. В крокодилам может даже точнее будет. Потому как общее количество запросов не говорит ни о чем.
|
Последний раз редактировалось: splav (28 Май 2007, 20:05), всего редактировалось 1 раз
|
|
|
|
|
|
|
|
|
Возраст: 39
C нами с 04.05.2006
Репутация: 63.9
|
|
splav, давай тогда точно обговорим, о оценке чего мы говорим... Производительности сервера или приложения?
Я лично говорю об оценки производительности приложения(сайта)
|
|
|
|
|
|
|
|
|
|
|
Возраст: 36
C нами с 22.01.2006
Репутация: 256.8
|
|
Есть два сайта:
1) Статика с огромным количеством мелких картинок размером до менее 0.5К
2) php с выборкой из сотни таблиц
О каком сравнении по qps может идти речь?
|
|
|
|
|
|
|
|
|
|
|
Возраст: 39
C нами с 04.05.2006
Репутация: 63.9
|
|
| splav писал(а): |
|
2) php с выборкой из сотни таблиц
|
Ну скажем так, что существует такая штука, как кэширование на уровне сайта. И если грамотно продумать кэширование, до можно добится лучших результатов, чем в статике...
По поводу статистики...
Если я правильно понял, то на "5.31 requests/sec" к веб-серверу приходится "qps: 307 " запросов к серверу БД. Если это так, то эт оччень нехорошо!
|
|
|
|
|
|
|
|
|
|
|
Возраст: 36
C нами с 22.01.2006
Репутация: 256.8
|
|
Petro, это противоречит законам сохранения При прочих равных проще отдать готовое, чем генерировать...
По поводу запросов - это не совсем так... ~16 qps к апачу на bt.unsorted.ru , скрипты трекера тоже к базе обращаются...
|
|
|
|
|
|
|
|
|
|
|
Возраст: 39
C нами с 04.05.2006
Репутация: 63.9
|
|
| splav писал(а): |
|
это противоречит законам сохранения При прочих равных проще отдать готовое, чем генерировать...
|
не догнал )) Видимо жара и вечер сказываются...
|
|
|
|
|
|
|
|
| |
|
|
