netwind

Рейтинг
419
Регистрация
06.05.2007

Mad_Man, не нужно быть семи пядей во лбу чтобы увидеть, что форум не сильно изменен. Никаких дополнительных бриждей регистрации тоже нет. В стандартной схеме ограничений в базе нет.

С высокой вероятностью индекса уникального нет.

Mad_Man:
Угу. А потом на первой же выборке по имени, а не по айдишнику, пользователи начнут получать удовольствие от коллизий.

Ну и много вы получили удовольствий от коллизий на этом форуме ? Коллизий нет. Удовольствий нет. А Vbulletin есть.

FC1488SM:
а как это сделать? Сначала нужно удалить уникальный индекс, а затем добавить обычный?

Например, еще до конвертации кодировки через phpmyadmin снимите галочку unique . (для меня эта программа бесполезна и могу наврать)

тупанул я, спутал 2 поля, name у меня это логин, а я думал необязательное имя, естественно он должен быть уникальным,

Обычно он делается уникальным в базе в качестве дополнительного ограничения . На всякий случай.

А вот CMS при регистрации все равно может делать отдельную проверку.

Например, в vbulletin ограничения в базе нет, а настройка движка есть.

Пробуйте.

А тут нельзя без костылей. Эта тема один сплошной костыль. Суть в том, что в cp1251 и utf8 была выбрана разная "сила сравнения". Буквы E и Ё считались разными, а потом в utf8 вдруг стали одинаковыми.

Раз индекс был создан уникальным, это было задумано в используемом вами движке. Если поменять collation у поля на utf8_bin, то различие больших и маленьких букв перестанет работать - перестанет правильно работать поиск по имени пользователя, например.

Все зависит от серьезности вашего подхода :

Если это говносайт, вы можете даже удалить дубли.

Либо переименовать юзеров вручную. Или хотя бы оценить объем работы. Связаться и предложить выбрать новое имя. Не так уж их и много должно быть. Помимо Артемов, обратите внимание на Женьков.

Вплоть до того чтобы собрать специальную таблицу сравнения для utf8, но считающую Е и Ё разными. (Это весьма необычно и сложно )

Ну для начала можно попробовать сделать индекс неуникальным и посмотреть как будет работать. Многие движки даже не пытаются опираться на уникальность индекса, проверяют все сами и нормально работают. Удалять индекс точно не нужно.

Andreyka:
Вам нужно быть умнее в выборе следующего админа. Кстати у меня на всех серверах в Hetzner стоит ondemand, а не performance. Проблем нет нигде.

Так а что ж вы про это сразу не написали ? Задним умом все хороши.

вот, Hetzer в принципе не скрывает свой умысел. Недавно тоже ставил debian на EX40 и в файле есть пометка :

cat /etc/default/cpufrequtils

### Hetzner Online AG - installimage

# cpu frequency scaling

ENABLE="true"

GOVERNOR="powersave"

MAX_SPEED="0"

MIN_SPEED="0"

А в других старых - "ondemand".

Ну что сказать ? Надо взять за правило это менять.

Dram:
Так чей это все так косяк - хедзнера или админа, настроившего серв с нуля?

А это важно ?

Да сколько платите - столько и делают вам.

Как заранее узнать, что разгон в этой конфигурации не будет работать, если времени на нагрузочное тестирование не выделить ?

Обычно эти штуки работают автоматически. Вон на первом же сервере работает - там 1800Mhz и это не максимум.

Может быть hetzner какие-то свои энергосберегающие плюшки стал сейчас устанавливать в образ, но раньше не замечал. У других хостеров бывало.

Может быть просто платформа более новая и менее обкатанная именно debian.

Dram, этот скрипт запускает dmidecode чтобы собрать всякую инфу. Но dmidecode не сработала правильно и поэтому не видно модель материнской платы. Но можно предположить, если 4 из 4 слотов памяти забиты симметрично, то NUMA там внезапно не образуется. наличие NUMA можно в dmesg посмотреть наверняка.

Зато видно, что на новом частота ядер сейчас снижена до 800. Лучшие друзья вебмастера любят экономить электричество.

Причем, на старых картинках вижу частоту 800 в период нагрузки http://s020.radikal.ru/i707/1506/d0/a165f3f7545c.jpg

можно заключить, что автоматический разгон частоты не работал.

Есть ли графики частоты в munin за большие периоды ? Это более точно покажет работоспособность механизма разгона.

начните с переключения cpu governor таким мини-скриптом. это в файл надо набрать и запустить:


for i in 0 1 2 3 4 5 6 7
do
echo 'performance' > /sys/devices/system/cpu/cpu$i/cpufreq/scaling_governor
done

Или просто в эти файлы в /sys/ вручную запишите значение. В конечном итоге вы должны увидеть 3.4Ghz в atop .

Потом убедитесь что время работы gzip сравнимо со старым. на двух сервера запускаете gzip с подсчетом времени работы :

time gzip -9 путь-к-большому-пребольшому-файлу-с-бекапом

Но мне кажется, дело именно в разгоне.

Dram,

запустить следующие команды

wget http://percona.com/get/pt-summary

bash ./pt-summary

вывод в виде текста скопировать на форум.

Dram, так сервер все равно вы купили на месяц. И предлагаемые мной тесты очень простые.

А почему упоминание о pt-summary пропустили ? Это просто программа . Запустить один раз.

Раз gzip так тормозит, то можно сжатием больших файлов gzip и протестировать . С максимальным сжатием с ключем -9 .

Dram, я так сложно пишу или что? почему бы не проделать описанные мной манипуляции ?

Всего: 6293