TrueNinja, а кто сказал, что в блоке питания нет проблемы? Симптоматика не характерная и только, а причиной быть по-прежнему может.
Температуры в норме - это в числах сколько? Раздельно по каждому ядру CPU, GPU и VRM
Думаю в этом контексте максимальным ограничением поддерживаемой памяти можно пренебречь
Это если не стоит выбор между двумя конкретными конфигурациями: с 32гб или 64 гб. В вопросе именно так описано, поэтому я не про максимальных поддерживаемый объём.
Базе нужна преимущественно память (но и ядра тоже), веб-серверу - в зависимости от качества написанного кода. Но параллелится нагрузка этого профиля хорошо.
Проглядел в тегах - похоже речь о VPS. Выясните у хостера - выделяются статично ядра физические или как повезёт и можно получить псевдоядра HT? И раз это VPS - то сколько в итоге дают вам ядер?
primary key в принципе не может быть null. auto_increment не может быть отдельно от первичного или уникального ключа. Подцепитесь штатным консольным клиентом и проверьте данные и show create table в консоли.
synchronous_commit в 8.4 уже был https://www.postgresql.org/docs/8.4/static/runtime...
Но перед выключением внимательно прочитайте что именно эта гайка делает. tradeoff между производительностью и риском потери последних коммитов при аварии.
huge pages - это к параметрам операционной системы. До 9.2 включительно можно было извращаться с libhugetlbfs. А вот начиная с какой версии можно было извращаться - хз. Впрочем до 32гб памяти можно не заморачиваться.
shared_buffers 32мб - это кошмар. Годится только если вы на каком-нибудь утюге запустились где всего 128-256мб памяти.
Чтобы понимать масштабы - postgresql будет обрабатывать данные только в shared_buffers. Чтобы сходить за данными в индекс - надо прочитать какие-то части индекса в shared_buffers (минимум 1 страничку корня btree, дальше как получится по запросу). Чтобы по полученным из индекса ctid сходить за данными - надо идти в таблицу, читать страницы в shared_buffers. И постоянно вытеснять другие страницы из shared_buffers. Потому что в 32мб можно поместить всего 32мб/8кб = 4096 страниц. Картину немного исправляет то, что postgresql использует системный файловый кеш. Но ходить настолько интенсивно в файловый кеш штука не бесплатная.
Наша в dataegret обычная рекомендация - отдельная машина только под базу, 25% RAM под shared_buffers. Т.е. никаких приложений на той же машине - иначе невозможно контролировать ресурсы. Какой-нибудь PHP случайно откушал на 20гб памяти и база в свопе - это из реальной практики. Если база влезает в память - то можно до 75% памяти отдать под shared_buffers.
Индексы - если кратко то всё сложнее. Ненужными индексами можно сделать хуже (особенно в зависимости от интенсивности записи). Писать ещё одно сочинение по тому как проставлять индексы настроения нет. Есть замечательный материал здесь: use-the-index-luke.com
Надо учитывать, что гайки и fsync и synchronous_commit - это для операций записи. Если много читаем с медленных дисков - они никак не повлияют на происходящее.
Что вы сделали для того, чтобы изменённые переменные окружения устанавливались заново при следующей авторизации пользователя? В PATH очевидно отсутствует место куда вы поставили бинарники базы.
Chvalov, по приведённому фрагменту не видно, что пространства имён не используются. Выведите var_dump(__NAMESPACE__); перед try, например.
Поймать всё что можно поймать - да, в php5 \exception, в php7 - \Throwable
Не во всех месяцах есть 31 день. И Postgresql об этом знает. Даже 29 день не всегда бывает. И об этом база тоже знает. И даст за такое безобразие как 31 ноября ошибку.
Выведите в notice переменные, посмотрите какие именно констрейнты создаются. Раз триггер ведёт себя странно - значит отлаживайте триггер.
Проще всего такое поймать если ходить в базу через баунсер в режиме пула транзакций. Где большим и заметным текстом написано: серверные prepared statements в пуле транзакций не поддерживаются. При том транзакционный пул выгоднее сохранения серверных prepared и потому рекомендация включить эмуляцию prepared statements в PDO (она дефолтно включена)
Explain запроса с одной таблицей так выглядеть не может. Либо вы показываете план не того запроса о котором говорите.
Плюс покажите show constraint_exclusion и (в psql) \d events2016m11 для примера того, что table constraint у вас есть.
Как обычный представитель подвида btree индексов для range поиска. Поиском от корня находим нужный MarketName, идём до минимальной подходящей даты и вычитываем все узлы до максимальной подходящей. С полученными id лезем в primary key и вычитываем непосредственно данные таблицы (т.к. innodb всегда кластеризован по первичному ключу и все вторичные индексы ссылаются на PK, а не на расположение данных в датафайлах)
Я проголосовал за изменение сложности вопроса на senior. exit, echo - не функции, а конструкции языка. Поэтому это где-то в потрохах Zend движка языка. Возможно глубоко в потрохах.
Температуры в норме - это в числах сколько? Раздельно по каждому ядру CPU, GPU и VRM