Evas: Большого запаса быть не должно иначе будут проблемы с Key buffer hit rate.
Т.е 300 метров это излишек уже? Понимаю что 3GB много, но опять же, опытным путем иду...
Evas:
внимательно посмотрите на вывод тюнера. Если просит их увеличить, значит текущих значений недостаточно.
Да вы знаете , он пишет что и буфера 64MB недостаточно при условии что будет выделено 60 GB памяти от моих 32 :)
Evas:
Эти параметры влияют на размеры кеша запросов. Как думаете, если результат запроса будет взять из кеша, вместо того, чтобы выполнять его каждый раз, нагрузка будет меньше?
Это логично, но влияют на что, ограничение в 64 MB на запрос и общее количество кеша? Вопрос скорее в том, что может быть много запросов которые идут мимо кеша, но их то не решить такими настройками.
Evas:
Т.е в будущее вы не смотрите?
Опять же в будущее вы не смотрите.
Нет, это вообще опасно.
Evas:
Спрашиваете почему я выбрал те или иные значения? Трудно сказать, нравится мне эти числа 😂 А если серьёзно - подобные значения подбираются опытным путём (одинаковыми для всех они не будут). Судя по размеру баз и результата тюнера я предложил их увеличить.
Ну так вы же сами говорите что тюнер как бы не дает ничего, а просто анализирует и тут же предлагаете увеличивать значения по мере разговора с тюнером.... парадоксец простите.
---------- Добавлено 06.02.2013 в 04:39 ----------
Evas: И дальше чего? сколько прошло с момента перезапуска мускл? 5-10 минут. Эти результаты ничего не значат, подождите хотябы несколько часов. И да, я не помню, чтобы укзывал key_buffer равным 2GB
Вы указали 1.7 G, я поставил 2, на сколько я понимаю , это не отражается на:
"Maximum possible memory usage", как и время о котором вы говорите, для накопления информации по запросам - само собой, но для подсчета буферов - простите ....
Чему именно? Тому, что макс. используемый объём озу увеличился? Нет, не только из за этого. Вы увеличили глобальный Key_buffer + другие буфферы, которые выделяются на каждый поток. Ключевым словом тут будет максимальный объём, именно столько будет использоваться при одновременных 600 подключений к вашему мускл, сейчас же у вас их меньше десятка...
Тому, что вы предлагаете настройки которые в реальности могут положить сервер.... не так? При достижении 600 конектов, где брать + 30 GB RAM ?
Вот именно, их меньше десятка, потому что mysql запущен 5 минут, а если посмотреть мой первый вывод mysqltuner, там где uptime составлял 8 часов, то будет понятно, что число 500 сессий достигается и не раз в течении суток, по этому сейчас когда 10, я очень рад этому )))) и вашим настройкам ))))) а в 12 часов дня мне надо будет нарисовать еще 30 GB памяти где-то ;))))) Это простите, как в php поставить memory_limit 10GB и молится что никто этого не заметит и не задействует :D Выглядит вяло....
// Фигня, в первом выводе не видно, но значение 600 взялось не спроста, при 500 , бывают ситуации в пиках когда too many connection .... так что расчет буферов производится из расчета 500-600 коyнектов.
В теории оптимизация должна зайти в такой момент когда mysql при 100% активности например убивает 60-70% ресурса сервера.... а дальше уже естественно будет проводиться работа по оптимизации запросов и доп. индексированию таблиц.....
// Что же касается "хостинга" то сервер "законсервирован", там не будет новых клиентов и ротации старых, по этому контент одинаков уже некоторое время, ну естественно за исключением обновлений которые касаются текущих клиентов, но они как бы не существенны, на 10 GB В день ни кто не ростет, движки 2 раза в день никто не меняет, собственно хочется понять и высчитать оптимальные значения для этой ситуации.
Вот тут Пишут что: "On Linux, there are thresholds of 256KB and 2MB where larger values may significantly slow down memory allocation, so you should consider staying below one of those values."
Другими словами ставить "что попало" не имеет смысла, так как буфер будет выделяться даже в том случае если он не будет использован целиком. Почему взято значение 32 M ? поясните мне пожалуйста. Я понимаю, что документация не носит в себе настроек для всех и всяк, но хотелось бы кроме сухого ответа в виде 32M услышать ответ на вопрос "почему именно 32?"
query_cache_size = 512M query_cache_limit = 64M
Допустим, но влияет ли это на формирование нагрузки? ;)
Интересная наводка: "It is better to keep the global setting small and change to a larger setting only in sessions that are doing large joins. Memory allocation time can cause substantial performance drops if the global size is larger than needed by most queries that use it."
Т.е по факту рекомендовано в глобальных значениях держать "некий минимум", а для сессий с большими join применять другое значение. Почему вы выбираете 64M ?
Это для : "Data in InnoDB tables: 29M (Tables: 58)" ???? 😮
---------- Добавлено 06.02.2013 в 04:18 ----------
Evas:
Смотрю хотите, чтобы всё сделали за вас. Наглость второе счастье, да?
Сделали за меня что? Вы о чем? Комменнтарии это когда человек рассказывает почему стоит выбрать данное значение , а не говорит что это "базовая оптимизация" :) Базовая для чего и для кого ? :)
Evas:
Я направил вас в нужное русло, изучайте вопрос самостоятельно, если хотите в будущем не создавать подобных тем.
Я понял ваше настроение, спасибо что уделили время, приму ваши советы к сведению.
Evas:
Если же, по какой-то причине у вас это не получается, наймите администратора.
Обязательно подумаю на эту тему.
---------- Добавлено 06.02.2013 в 04:25 ----------
Кстати, при применении ваших настроек, результат mysqltuner выглядит вот так:
[!!] Maximum possible memory usage: 60.4G (192% of installed RAM) [OK] Slow queries: 0% (0/573) [OK] Highest usage of available connections: 0% (3/600) [OK] Key buffer size / total MyISAM indexes: 2.0G/1.7G [!!] Key buffer hit rate: 93.0% (40K cached / 2K reads) [OK] Query cache efficiency: 48.9% (258 cached / 528 selects) [OK] Query cache prunes per day: 0 [OK] Sorts requiring temporary tables: 0% (0 temp sorts / 32 sorts) [!!] Temporary tables created on disk: 40% (14 on disk / 35 total) [OK] Thread cache hit rate: 85% (3 created / 20 connections) [OK] Table cache hit rate: 87% (51 open / 58 opened) [OK] Open file limit used: 1% (101/8K) [OK] Table locks acquired immediately: 100% (326 immediate / 326 locks) [OK] InnoDB data size / buffer pool: 29.3M/50.0M
Да без проблем, что он только даст , не совсем понимаю:
-------- General Statistics -------------------------------------------------- [--] Skipped version check for MySQLTuner script [OK] Currently running supported MySQL version 5.1.66-cll [OK] Operating on 64-bit architecture
-------- Storage Engine Statistics ------------------------------------------- [--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster [--] Data in MyISAM tables: 5G (Tables: 2512) [--] Data in InnoDB tables: 29M (Tables: 58) [--] Data in MEMORY tables: 0B (Tables: 12) [!!] Total fragmented tables: 141
-------- Security Recommendations ------------------------------------------- [OK] All database users have passwords assigned
-------- Performance Metrics ------------------------------------------------- [--] Up for: 8h 49m 32s (31M q [981.693 qps], 202K conn, TX: 109B, RX: 2B) [--] Reads / Writes: 94% / 6% [--] Total buffers: 796.0M global + 9.2M per thread (600 max threads) [OK] Maximum possible memory usage: 6.2G (19% of installed RAM) [OK] Slow queries: 0% (682/31M) [OK] Highest usage of available connections: 24% (148/600) [OK] Key buffer size / total MyISAM indexes: 512.0M/1.7G [OK] Key buffer hit rate: 100.0% (2B cached / 237K reads) [OK] Query cache efficiency: 29.0% (8M cached / 29M selects) [!!] Query cache prunes per day: 46333585 [OK] Sorts requiring temporary tables: 0% (1K temp sorts / 475K sorts) [!!] Joins performed without indexes: 6944 [!!] Temporary tables created on disk: 38% (237K on disk / 623K total) [OK] Thread cache hit rate: 99% (148 created / 202K connections) [OK] Table cache hit rate: 24% (3K open / 12K opened) [OK] Open file limit used: 62% (5K/8K) [OK] Table locks acquired immediately: 99% (23M immediate / 23M locks) [OK] InnoDB data size / buffer pool: 29.3M/50.0M
-------- Recommendations ----------------------------------------------------- General recommendations: Run OPTIMIZE TABLE to defragment tables for better performance MySQL started within last 24 hours - recommendations may be inaccurate Enable the slow query log to troubleshoot bad queries Adjust your join queries to always utilize indexes When making adjustments, make tmp_table_size/max_heap_table_size equal Reduce your SELECT DISTINCT queries without LIMIT clauses Variables to adjust: query_cache_size (> 32M) join_buffer_size (> 4.0M, or always use indexes with joins) tmp_table_size (> 200M) max_heap_table_size (> 200M)
Uptime не велик , но и не полчаса... С кешом игрался, можно чуток увеличить, но все равно значение в районе нескольких миллионов. Так как вижу NO_CACHE или как-то там запросы про процессам. Общий объем баз 5 GB, сайтов не много, но они посещаемые... Я полагаю для такого сервера 200 сайтов это не много :D :D :D Понимаю что "считать сайтами" не верно, но реально из них есть 5 которые по 50k+ uniq в сутки, остальные блекло смотрятся на их фоне, типа 1-5k uniq и даже меньше есть.... Рядом есть такой же сервер с практически такими же настройками но там иначе, тяжеловесов нет, но зато сайтов 1000+ чувствует себя в 100 раз лучше )))) полагаю что таки проблемы с запросами (базой).....
Еще думаю, что может совокупность факторов играет роль, например пишутся временные таблицы, тут же рядом может бекап запустится.... а следом уже комом набираются процессы php которые попросту не завершаются. и так по кругу пока есть свободный ресурс..... сейчас буферы немного увеличу по этой формуле:
Что бы "Maximum possible memory usage:" было около 20 GB, я же понимаю это нормальным, для 32 гиг памяти.. ? остальные 13 останутся под все остальное, memory_limit и прочее в php есть, т.е выедать под ноль не должно.
Посмотрим как после этого пару суток вести себя будет ..... возможно перенос в shm решает вопрос в корне...хотя вы говорите что что-то настроили бы иначе... а точнее "Все..." , жду плотных комментариев :D
Evas: Наиболее распространённые причины этого:
а) не хватает места отведенного директивами tmp_table_size и max_heap_table_size
Тюнил и тут, причем от 100M до 3 GB и heap и table_size, пофик, результат тот же :D
Evas:
б) в ваших основных таблицах имеются поля типа TEXT или BLOB, в результате все временные даные, которые являются результатом запросов на основные таблички пишутся на диск, а не в ОЗУ.
А как же в таких случаях выживают хостеры? :) Таблички то ясное дело что не мои :D
Evas:
Перепроверьте, не включен ли часом binlog или что-то иное...
Нету.
Evas:
Судя по кол-ву памяти - размеры буферов у вас маловаты, да и вообще... Прежде чем что либо настраивать необходимо выяснить ряд моментов.
Какие моменты? Какие буферы маловаты на ваш взгляд?
Evas:
Прогоните Mysqltuner'ом, он подскажет основные моменты. Можете приложить сюда результат.
Треш это а не софт, гоняю им, результата нет , показывает почти одно и то же, по буферам я сейчас специально урезал, что бы не более 10GB памяти кушало, ибо в моменты когда оно все заедает с сервером работать весьма сложно, но обращая внимание на график который я привел выше, возможно станет полегче из за переноса таблиц в shm.
При этом логи веб сервера занимают около 500 MB , это те которые актуальны , естественно они ротируются.
MySQL ведет только error log, который весит около 2х метров :D
Вопрос про tmp таблицы актуален, машинка оснащена 32 гигами памяти.... почему временные таблицы выпадают на диск?
---------- Добавлено 06.02.2013 в 01:59 ----------
Перенес в shm временные таблицы, сервер конечно отпустило но понятно как бы почему, вопрос остается открытый, мне не ясно почему SQL пишет на диск если есть свободная память.... (с точки зрения временных таблиц). Винт у меня разбит на "/" и "/tmp", раньше писало в /tmp , отдельный раздел, меньше вопросов было, но со временем отрезанного (не LVM) под /tmp стало не хватать, перенесли в "/" этим собственно и добили. Сейчас в shm с меньшим i/o пишет конечно, но *****, почему не сразу в память? Какие буфера крутить ? куда? :)
dedo: Напоминаем читателям о том, что все еще продолжает свое действие акция, согласно условий которой можно приобрести следующий тариф: 5 GB HDD, 200 GB трафика, 50 доменов на акаунт, ssh, cPanel , всего за $6.50 в месяц, при оплате сроком на 3,6,12,24 месяца действуют существенные скидки.Cкидка еще действует?
dedo: И еще сайт практически просто продающая страница. Все мануалы после оплаты?
Что значит мануалы? Какие мануалы? После регистрации вам будет направлено письмо с техническими параметрами доступа к cPanel, DNS информацией и прочим, как работать с cPanel изложено в очень обширной документации на сайте самой cPanel (www.cpanel.net). Или о каких мануалах речь?
'[umka: ;11396477']Назвать это АПИ язык не поворачивается. Это, скорее, сильно недружественный и извращённый интерфейс, придуманный с бодуна кем-то с тяжёлым советским прошлым. Интерфейс принимает запросы, подписанные ГОСТовской ЭЦП.
Ну а как же без подписи-то? Информация ведь жутко секретная. Мало ли какой враг государства её получит.
На днях как раз изобретали скрипт для автоматического получения этого списка. На всё ушло полдня, вместе с танцами с бубном вокруг openssl и ГОСТовской ЭЦП.
А всего-то нужно файлик скачать!
Хотя, было бы странно, если б было как-то по-другому... по-нормальному.
Цифровые подписи ... это сила, информация то действительно внутренняя ...... не важно что она не супер важная, но реально то .... файлик скачал.... в инет выложил.... и всем понятно кто в блоках.... в том числе и злоумышленникам :D Как-то непонятно :D
Большого запаса быть не должно иначе будут проблемы с Key buffer hit rate.
Т.е 300 метров это излишек уже? Понимаю что 3GB много, но опять же, опытным путем иду...
внимательно посмотрите на вывод тюнера. Если просит их увеличить, значит текущих значений недостаточно.
Да вы знаете , он пишет что и буфера 64MB недостаточно при условии что будет выделено 60 GB памяти от моих 32 :)
Эти параметры влияют на размеры кеша запросов. Как думаете, если результат запроса будет взять из кеша, вместо того, чтобы выполнять его каждый раз, нагрузка будет меньше?
Это логично, но влияют на что, ограничение в 64 MB на запрос и общее количество кеша? Вопрос скорее в том, что может быть много запросов которые идут мимо кеша, но их то не решить такими настройками.
Т.е в будущее вы не смотрите?
Опять же в будущее вы не смотрите.
Нет, это вообще опасно.
Спрашиваете почему я выбрал те или иные значения? Трудно сказать, нравится мне эти числа 😂 А если серьёзно - подобные значения подбираются опытным путём (одинаковыми для всех они не будут). Судя по размеру баз и результата тюнера я предложил их увеличить.
Ну так вы же сами говорите что тюнер как бы не дает ничего, а просто анализирует и тут же предлагаете увеличивать значения по мере разговора с тюнером.... парадоксец простите.
---------- Добавлено 06.02.2013 в 04:39 ----------
И дальше чего? сколько прошло с момента перезапуска мускл? 5-10 минут. Эти результаты ничего не значат, подождите хотябы несколько часов.
И да, я не помню, чтобы укзывал key_buffer равным 2GB
Вы указали 1.7 G, я поставил 2, на сколько я понимаю , это не отражается на:
"Maximum possible memory usage", как и время о котором вы говорите, для накопления информации по запросам - само собой, но для подсчета буферов - простите ....
Чему именно? Тому, что макс. используемый объём озу увеличился?
Нет, не только из за этого. Вы увеличили глобальный Key_buffer + другие буфферы, которые выделяются на каждый поток.
Ключевым словом тут будет максимальный объём, именно столько будет использоваться при одновременных 600 подключений к вашему мускл, сейчас же у вас их меньше десятка...
Тому, что вы предлагаете настройки которые в реальности могут положить сервер.... не так? При достижении 600 конектов, где брать + 30 GB RAM ?
Вот именно, их меньше десятка, потому что mysql запущен 5 минут, а если посмотреть мой первый вывод mysqltuner, там где uptime составлял 8 часов, то будет понятно, что число 500 сессий достигается и не раз в течении суток, по этому сейчас когда 10, я очень рад этому )))) и вашим настройкам ))))) а в 12 часов дня мне надо будет нарисовать еще 30 GB памяти где-то ;))))) Это простите, как в php поставить memory_limit 10GB и молится что никто этого не заметит и не задействует :D Выглядит вяло....
// Фигня, в первом выводе не видно, но значение 600 взялось не спроста, при 500 , бывают ситуации в пиках когда too many connection .... так что расчет буферов производится из расчета 500-600 коyнектов.
В теории оптимизация должна зайти в такой момент когда mysql при 100% активности например убивает 60-70% ресурса сервера.... а дальше уже естественно будет проводиться работа по оптимизации запросов и доп. индексированию таблиц.....
// Что же касается "хостинга" то сервер "законсервирован", там не будет новых клиентов и ротации старых, по этому контент одинаков уже некоторое время, ну естественно за исключением обновлений которые касаются текущих клиентов, но они как бы не существенны, на 10 GB В день ни кто не ростет, движки 2 раза в день никто не меняет, собственно хочется понять и высчитать оптимальные значения для этой ситуации.
Ну как что, я вижу основные проблемы, используемые движки, а также размер прочих нужных вещей.
key_buffer_size = 1,7G
Согласен, его подбираем по размеру общему индексов, это значение так же уже было в фазе 2 и 3 GB, т.е с небольшим запасом.
tmp_table_size = 256M
max_heap_table_size = 256M
Сейчас стоит 200 M, что это дает? Кстати, установка этих переменных не влияет на размер создаваемых временных таблиц.....
sort_buffer = 32M
http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html#sysvar_sort_buffer_size
Вот тут Пишут что: "On Linux, there are thresholds of 256KB and 2MB where larger values may significantly slow down memory allocation, so you should consider staying below one of those values."
Другими словами ставить "что попало" не имеет смысла, так как буфер будет выделяться даже в том случае если он не будет использован целиком. Почему взято значение 32 M ? поясните мне пожалуйста. Я понимаю, что документация не носит в себе настроек для всех и всяк, но хотелось бы кроме сухого ответа в виде 32M услышать ответ на вопрос "почему именно 32?"
query_cache_size = 512M
query_cache_limit = 64M
Допустим, но влияет ли это на формирование нагрузки? ;)
join_buffer_size = 64M
http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html
Интересная наводка: "It is better to keep the global setting small and change to a larger setting only in sessions that are doing large joins. Memory allocation time can cause substantial performance drops if the global size is larger than needed by most queries that use it."
Т.е по факту рекомендовано в глобальных значениях держать "некий минимум", а для сессий с большими join применять другое значение. Почему вы выбираете 64M ?
innodb_flush_method = O_DIRECT
innodb_flush_log_at_trx_commit = 0
Это для : "Data in InnoDB tables: 29M (Tables: 58)" ???? 😮
---------- Добавлено 06.02.2013 в 04:18 ----------
Смотрю хотите, чтобы всё сделали за вас. Наглость второе счастье, да?
Сделали за меня что? Вы о чем? Комменнтарии это когда человек рассказывает почему стоит выбрать данное значение , а не говорит что это "базовая оптимизация" :) Базовая для чего и для кого ? :)
Я направил вас в нужное русло, изучайте вопрос самостоятельно, если хотите в будущем не создавать подобных тем.
Я понял ваше настроение, спасибо что уделили время, приму ваши советы к сведению.
Если же, по какой-то причине у вас это не получается, наймите администратора.
Обязательно подумаю на эту тему.
---------- Добавлено 06.02.2013 в 04:25 ----------
Кстати, при применении ваших настроек, результат mysqltuner выглядит вот так:
Полагаю сему виной как раз join_buffer_size 64M ?
Да без проблем, что он только даст , не совсем понимаю:
Фрагментация - фигова, согласен, проведу optimize. еще?
Uptime не велик , но и не полчаса... С кешом игрался, можно чуток увеличить, но все равно значение в районе нескольких миллионов. Так как вижу NO_CACHE или как-то там запросы про процессам. Общий объем баз 5 GB, сайтов не много, но они посещаемые... Я полагаю для такого сервера 200 сайтов это не много :D :D :D Понимаю что "считать сайтами" не верно, но реально из них есть 5 которые по 50k+ uniq в сутки, остальные блекло смотрятся на их фоне, типа 1-5k uniq и даже меньше есть.... Рядом есть такой же сервер с практически такими же настройками но там иначе, тяжеловесов нет, но зато сайтов 1000+ чувствует себя в 100 раз лучше )))) полагаю что таки проблемы с запросами (базой).....
Еще думаю, что может совокупность факторов играет роль, например пишутся временные таблицы, тут же рядом может бекап запустится.... а следом уже комом набираются процессы php которые попросту не завершаются. и так по кругу пока есть свободный ресурс..... сейчас буферы немного увеличу по этой формуле:
Что бы "Maximum possible memory usage:" было около 20 GB, я же понимаю это нормальным, для 32 гиг памяти.. ? остальные 13 останутся под все остальное, memory_limit и прочее в php есть, т.е выедать под ноль не должно.
Посмотрим как после этого пару суток вести себя будет ..... возможно перенос в shm решает вопрос в корне...хотя вы говорите что что-то настроили бы иначе... а точнее "Все..." , жду плотных комментариев :D
Наиболее распространённые причины этого:
а) не хватает места отведенного директивами tmp_table_size и max_heap_table_size
Тюнил и тут, причем от 100M до 3 GB и heap и table_size, пофик, результат тот же :D
б) в ваших основных таблицах имеются поля типа TEXT или BLOB, в результате все временные даные, которые являются результатом запросов на основные таблички пишутся на диск, а не в ОЗУ.
А как же в таких случаях выживают хостеры? :) Таблички то ясное дело что не мои :D
Перепроверьте, не включен ли часом binlog или что-то иное...
Нету.
Судя по кол-ву памяти - размеры буферов у вас маловаты, да и вообще... Прежде чем что либо настраивать необходимо выяснить ряд моментов.
Какие моменты? Какие буферы маловаты на ваш взгляд?
Прогоните Mysqltuner'ом, он подскажет основные моменты. Можете приложить сюда результат.
Треш это а не софт, гоняю им, результата нет , показывает почти одно и то же, по буферам я сейчас специально урезал, что бы не более 10GB памяти кушало, ибо в моменты когда оно все заедает с сервером работать весьма сложно, но обращая внимание на график который я привел выше, возможно станет полегче из за переноса таблиц в shm.
Жестоки однако временные таблицы, смотрим график после переноса их на shm.
my.cnf выглядит вот так:
При этом логи веб сервера занимают около 500 MB , это те которые актуальны , естественно они ротируются.
MySQL ведет только error log, который весит около 2х метров :D
Вопрос про tmp таблицы актуален, машинка оснащена 32 гигами памяти.... почему временные таблицы выпадают на диск?
---------- Добавлено 06.02.2013 в 01:59 ----------
Перенес в shm временные таблицы, сервер конечно отпустило но понятно как бы почему, вопрос остается открытый, мне не ясно почему SQL пишет на диск если есть свободная память.... (с точки зрения временных таблиц). Винт у меня разбит на "/" и "/tmp", раньше писало в /tmp , отдельный раздел, меньше вопросов было, но со временем отрезанного (не LVM) под /tmp стало не хватать, перенесли в "/" этим собственно и добили. Сейчас в shm с меньшим i/o пишет конечно, но *****, почему не сразу в память? Какие буфера крутить ? куда? :)
Напоминаем читателям о том, что все еще продолжает свое действие акция, согласно условий которой можно приобрести следующий тариф: 5 GB HDD, 200 GB трафика, 50 доменов на акаунт, ssh, cPanel , всего за $6.50 в месяц, при оплате сроком на 3,6,12,24 месяца действуют существенные скидки.Cкидка еще действует?
Тот тариф о котором вы пишите действует, вот условия: https://onyx.net.ua/hid.2.0.1.2.php
И еще сайт практически просто продающая страница. Все мануалы после оплаты?
Что значит мануалы? Какие мануалы? После регистрации вам будет направлено письмо с техническими параметрами доступа к cPanel, DNS информацией и прочим, как работать с cPanel изложено в очень обширной документации на сайте самой cPanel (www.cpanel.net). Или о каких мануалах речь?
Что под аптеку посоветуешь?
Видимо ничего, это ведь из раздела фармы? или есть лицензии на аптеку?
Доброго времени суток. Какие ресурсы запрещены? Например-фарма,порно,доры и т.д.... Плиз-простым русским языком...
Запрещены: фарма, доры, спам, вирусы.
Разрешены: легальный адалт, все прочее (белое, серенькое)
;11396477']Назвать это АПИ язык не поворачивается. Это, скорее, сильно недружественный и извращённый интерфейс, придуманный с бодуна кем-то с тяжёлым советским прошлым. Интерфейс принимает запросы, подписанные ГОСТовской ЭЦП.
Ну а как же без подписи-то? Информация ведь жутко секретная. Мало ли какой враг государства её получит.
На днях как раз изобретали скрипт для автоматического получения этого списка. На всё ушло полдня, вместе с танцами с бубном вокруг openssl и ГОСТовской ЭЦП.
А всего-то нужно файлик скачать!
Хотя, было бы странно, если б было как-то по-другому... по-нормальному.
Цифровые подписи ... это сила, информация то действительно внутренняя ...... не важно что она не супер важная, но реально то .... файлик скачал.... в инет выложил.... и всем понятно кто в блоках.... в том числе и злоумышленникам :D Как-то непонятно :D