Установка pdo sqlite debian

unixforum.org

Форум для пользователей UNIX-подобных систем

ошибка установки pdo_sqlite в Debian (ошибка установки pdo_sqlite в Debian Lenny)

ошибка установки pdo_sqlite в Debian

Сообщение StepnoySlom » 23.01.2010 17:02

Что имеем:
Debian linny
Plesk 9.3.0

нужно установить
pdo_sqlite

./configure
make
make install

копирую содержимое .libs в /usr/lib/php5/20060613+lfs

потом создаю файл pdo_sqlite.ini в /etc/php5/apache2/conf.d
# configuration for phph SQLIte: module
extension=pdo_sqlite.so
в остальных conf.d он тоже есть

Но почему то не работает. в чем не прав?

Re: ошибка установки pdo_sqlite в Debian

Сообщение distress » 23.01.2010 18:07

эта гадость ставит свои пакеты(апач, пхп. ) и кладет их куда-то очень глубоко (так было на рахате). так что путь /usr/lib/php5/ скорее всего неправильный.
phpinfo() может помочь в поисках правильного пути.

Re: ошибка установки pdo_sqlite в Debian

Сообщение StepnoySlom » 23.01.2010 20:30

Пробовал, не дает видимо плекс опять все портит

Re: ошибка установки pdo_sqlite в Debian

Сообщение distress » 23.01.2010 22:43

вот тут у меня лежит конфиг пхп /usr/local/psa/admin/conf/php.ini , а не в /etc. повезло если путь совпадет. бо ссылка не открылась.
вобще советую отказаться от plesk раз и навсегда. если нужно что-то подобное — есть прекрасный cpanel. ну или не совсем то, но лучше чем ничего — webmin.

Re: ошибка установки pdo_sqlite в Debian

Сообщение StepnoySlom » 26.01.2010 22:49

Снес цпанель, дубовая панель, заного все установил, дополнительно добавил модули, все заработало под virtualminom.

Спасибо за cовет, изучение CPanel я приберег к моменту аренды дедика на vpsках вполне хватит ispmanager и virtualmina, причем с 2 вариантом начинаешь больше разбираться в архитектуре системы с которой работаешь c directadmin’ом работал мало, но он мне показался тоже достаточно симпатичным

источник

Как установить sqlite на Debian

Мне нужно установить SQLite на мой Debian VPS сервер. Кто-нибудь может мне помочь? Пожалуйста, дайте мне шаги, потому что я новичок здесь и понятия не имею.

3 Ответа

Из ваших комментариев выше я понял, что вы хотите использовать sqlite с PHP. Хотя, это старый вопрос, вот как это сделать на будущее.

PHP может взаимодействовать с базами данных SQLite с помощью расширения pdo-sqlite. На текущий Debian вам необходимо установить пакет php5-sqlite . Это позволит установить и активировать модуль в вашем php.ini:

Вы можете взаимодействовать с базами данных SQLite из командной строки с помощью средств, предусмотренных в пакете sqlite или sqlite3 . Вы можете установить их аналогично. Обратите внимание, что эти инструменты не предоставляют никаких расширений PHP.

Если вы хотите установить только SQLite3 (в вашем случае, на сервере):

Если вам нужны пакеты разработки (для построения программ на основе библиотек sqlite3):

Похожие вопросы:

Я пытаюсь создать сервер Kerberos на компьютере Debian, но я вроде как потерял все файлы конфигурации. Может ли кто-нибудь рассказать мне хороший пошаговый учебник о том, как установить и настроить.

Как установить Debian пакетов на Alpine? Например: wget https://dl.influxdata.com/influxdb/releases/influxdb_0.13.0_armhf.deb sudo dpkg -i influxdb_0.13.0_armhf.deb

Мне нужно установить tkinter на debian. После некоторых исследований [1] [2] , я заметил, что Tkinter должен быть автоматически установлен с Python. Однако, когда я пытаюсь импортировать модуль, я.

Я хотел бы установить самые новые ruby и rails на моем сервере debian lenny. Я нашел пакет http://packages.debian.org/lenny-backports/ruby1.9.1-full , но когда я пытаюсь установить его с помощью я.

Я пытаюсь установить Mono-Complete на свежую совершенно новую установку Debian 8 для того, чтобы использовать ASP.NET 5 согласно (code.visualstudio.com/docs), следуя документации mono-project.com.

Я хочу скомпилировать Unreal Engine на моем поле Debian Liunx (testing), для которого требуется установить пакет mono libmono-corlib4.0-cil , который зависит от mono-runtime в версии 3. Однако на.

Я пытаюсь запустить Debian stretch box с vagrant на Mac OSX. Я изменил поле на fujimakishouten/debian-stretch64 , чтобы установить это поле.

gitosis заменяется на gitolite в debian wheezy. Но самый простой способ продолжить работу после обновления — это просто установить gitosis из исходного кода или пакета debian. Возможно ли это на.

Я недавно изучал разработку OpenGL и после просмотра учебника заметил, что мне не удалось скомпилировать свой код. Ссылки, которые кажутся двумя функциями, добавленными специально в SDL 2.0, не.

Точно так же, как я могу установить XDebug на docker’s официальный php-fpm-alpine образ? но вместо альпийского изображения я ищу изображение на основе debian ( php:7.1-fpm-stretch ). По сути.

источник

Решено. php_pdo_mysql и debian

#1 azsx

Основатель

5 084 сообщений

#2 rech

Основатель

1 480 сообщений

azsx (07 Апрель 2013 — 18:15) писал:

нужно дописать в php.ini
тут можно почерпнуть инфы:
http://karoshiethos. ysql-on-centos/

подключиться и проверить работоспособность через php:

Установка PHP-расширения PDO на Debian

Устанавливаем утилиты и репозиторий пакетов:

apt-get install php5-dev php-pear

pecl install pdo
pecl install pdo_mysql

mv /etc/php5/conf.d/pdo.ini.disabled /etc/php5/conf.d/pdo.ini
mv /etc/php5/conf.d/pdo_mysql.ini.disabled /etc/php5/conf.d/pdo_mysql.ini

invoke-rc.d apache2 restart

Замечание:
Если PDO собирается, как подгружаемое расширение ( не рекомендуется), то все PDO драйверы должны быть загружены после загрузки самого PDO.

При инсталляции PDO в качестве подгружаемого модуля в файл php.ini необходимо внести изменения, чтобы расширение PDO загружалось автоматически при запуске PHP. Также туда придется включить загрузку некоторых драйверов баз данных; при этом убедитесь, что они перечислены после строки pdo.so, так как PDO должно загрузиться первым. Если вы устанавливаете PDO и драйверы как статичные модули, этот шаг можно пропустить

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

в phpinfo() можно увидеть например так:
tt1.gif 5,01К 14 Количество загрузок:

источник

Тюнинг SQLite для PHP

Начало

Не так давно мне захотелось сделать свой сервис промо-кодов для одного своего проекта. В выборе платформы я не долго сомневался. Раз у меня есть сервер с развернутым PHP-окружением, то и сам сервис смело можно писать на PHP (тем более, что я с ним знаком). В качестве СУБД мне захотелось попробовать SQLite (хотя на сервере развернуты MySQL и PostgreSQL). Причина — проще переносить на “боевое” окружение (просто скопировать папку), проще разворачивать на “голом” сервере (кроме PHP ничего не нужно). Дополнительно хотелось упростить бэкап (планировал использовать снэпшоты диска + простое копирование получившегося “среза”).

Но прежде, чем использовать, необходимо проверить применимость и производительность данного решения.

Железо

Тестирование происходило на 2х объектах:

• Рабочая станция. Intel i5. 12GB RAM. SSD + HDD (WD Black). Windows 8. Используется OpenServer для запуска PHP.
• Облако в Selectel. Debian 6. Тут будет стоять сервис. Установлен LAMP в дефолтной конфигурации. Разве что Apache еще сильнее урезал, в угоду уменьшения потребления памяти.

Предварительная оценка

Для начальной оценки производительности был написан простой скрипт:

Последовательно вставляем 1000 записей в таблицу. Замеряем затраченное время. Вычисляем количество операций в секунду.
В принципе, для грубой оценки большего и не надо.
Обращаю внимание, что я специально не использовал транзакции. Каждая операция пойдет в собственной транзакции. Этот режим работы ближе к реальному использованию базы в многопоточном режиме.

А теперь результаты:
Для SSD диска получили оценку в 365 операций в секунду. Неплохо.
Для HDD получили всего 13 операций. Печально. Но что же скажет сервер?
А сервер порадовал. 210 операций.
В целом, оценка производительности на сервере вполне приличная. Можно продолжать тестирование работы PHP с SQLite. Только сразу же делаем отметку, что для сервера необходимо использовать быструю файловую подсистему (SSD).
В нашем случае, как я уже говорил, используется облако в Selectel. SSD выступает там как кэш между дисками и облачными машинами (во всяком случае, так я понял по рассказам небезызвестного amarao).

Многопоточный режим работы

Теперь попробуем ответить на вопрос, сумеет ли база работать в многопоточном режиме.
Читаем замечательный цикл статей о SQLite: habrahabr.ru/post/149356
И видим, что для многопоточного режима необходимо включать WAL-журнал. Добавим в инициализацию БД строчку (после открытия):

И сразу же прогоним тест:
SSD: 2000 транзакций в секунду. Показатель вырос более чем в 5 раз!
HDD: 42 операции. Рост в 3 раза.
Сервер: 1000 операций. Рост почти в 5 раз.

Очень неожиданные результаты. Простое изменение режима журнала дает рост в 5 раз.
Следующим этапом перепишем скрипт на многопоточность.
Многопоточность будем достигать через вызов PHP-скрипта несколько раз в нескольких потоках (ближе к реальной работе сайтов). Для этого воспользуемся утилитой AB (Apache Benchmark).

Получившийся текст скрипта:

Из скрипта ушел замер скорости вставки, это нам даст AB. Теперь инициализация проводится только 1 раз, т.к. идет работа с одной БД.
Дополнительно, установил

Это необходимо для того, чтобы при попытке многопоточной записи, процесс ждал некоторое время (я задал 5 секунд) своей очереди, а не сразу падал с тем, что “SQLITE_BUSY”.

Результаты:
SSD: 970 операций в секунду. Более чем достаточно.
HDD: 35 операций.
Сервер: 90 операций при тесте с локальной машины и 210 при запуске AB с сервера. Очень большая разница с запуском на SSD. Судя по всему, она обусловлена различиями в настройке систем (на сервере Apache урезан до возможного минимума).
Дополнительно следует отметить, что локальные показатели очень сильно плавают, сказывается облачность сервера. От меня до сервера почти полторы тысячи километров.
В любом случае, даже если брать минимум, 90 операций в секунду, то этого более чем достаточно, на мой взгляд. К примеру, Хабр имеет в среднем 30 просмотров в секунду (конечно, сильные пики днем, но и до Хабра расти и расти).

В дальнейшем показатели для SSD и HDD берутся при локальном тесте. А для сервера — с удаленной машины.
Тестирование сервера и SSD происходит путем запуска 1000 запросов в 10 потоках. Для HDD — 100 запросов в 10 потоков.

Усложнение

Напомню, в тесте был 1 простой INSERT запрос. В принципе, хорошо иметь сервис, выполняющий 1 операцию на базе. Но это очень далеко от реальности. Усложним до трех запросов (1 SELECT, 1 UPDATE и 1 INSERT).
Итоговая функция testIteration:

Понятно, что можно обойтись и без SELECT-запроса, но тем не менее, у нас тест, а не соревнования по оптимизации.

Показатели:
SSD: от 420 запросов. От запуска к запуску показатель падает.
HDD: от 20 запросов (и падает).
Сервер: от 65 запросов (и падает).

Оптимизация БД

Падение производительности мне не понравилось. Ну что же, попробуем исправить данную проблему. А конкретно — добавим индексы. Поиск у нас происходит всего по одному полю, так что его и добавим в индекс.

В инициализацию добавляем строчку

Результаты:
SSD: 671 запрос. Очень неплохо.
HDD: от 25 до 12 запросов. Не знаю, в чем проблема, но результат не показателен. Возможно, связано с тем, что сервер и SSD я тестирую 1000 запросов в 10 потоках, а HDD — 100 запросов в 10 потоках. Там меньше данных на порядок. Но на такой разброс не должно было влиять.
Сервер: 60 запросов.

Ну что же, результаты меня вполне радуют. Вот только у нас уже 2 операции изменения базы, где моя транзакция? Добавим ее:

И опять результаты:
SSD: от 720 запросов.
HDD: от 30 запросов. Причем на этот раз показатель достаточно стабилен.
Сервер: от 70 запросов.

Оптимизация отказов БД

Apache Benchmark помимо выполнения запросов, следит и за успешностью запросов. Берется длина ответа и все ответы, длиннее или короче исходного, считаются ошибками. Интересно, что при тестировании уже давно стали выходить подобные проблемы. Пускай всего с десяток на 1000 запросов, но тем не менее.
В логах сообщение “SQLite3::exec(): database is locked”. Странно, WAL-режим, транзакции, и все равно “database is locked”. Выход нашелся в рассылке SQLite: http://www.mail-archive.com/sqlite-users@sqlite.org/msg05525.html
В мультипоточном режиме необходимо использовать не “BEGIN”, а “BEGIN IMMEDIATE” или “BEGIN EXCLUSIVE”. Специальные транзакции для мультипоточной работы. Режим “BEGIN EXCLUSIVE” еще иногда давал мне эту проблему, а вот режим “BEGIN IMMEDIATE” ее решил полностью.

А теперь итоговые тесты:
SSD: от 700 запросов.
HDD: от 30 запросов. Причем показатель достаточно стабилен.
Сервер: от 53 запроса. Странно, ожидал около 70. Но это облако, о стабильности говорить не приходится.

Кстати, показатель количества запросов немного падает со временем. На чистой базе SSD выдает 1000 запросов. На “грязной” — до 350. При этом в базе скопилось около 50000 записей.

Стоит добавить, что если однопоточный тест усложнить, как мы усложнили многопоточный (1 SELECT, 1 UPDATE и 1 INSERT запрос + транзакция + индексы), то на SSD выдается результат в 1500 итераций в секунду. Есть, куда стремиться. При этом с ростом БД производительность падает примерно в 2 раза медленнее, чем для мультипоточного режима.
Повторные тесты не выявили серьезных преимуществ однопоточого режима работы SQLite относительно многопоточного.

В принципе, тест показал достаточно хорошие результаты. Пусть он местами и противоречив, спорен и недостаточно научен. Но тем не менее, лично для меня, оценку работоспособности связки SQLite и PHP вполне показал.

Сравнение с другими СУБД

Результаты:
SQLite: 993 запроса в секунду. Вполне ожидаемый результат.
PostgreSQL: 178 202 запроса в секунду. Довольно мало. Судя по всему, проблема в настройке по умолчанию.
MS SQL: 1400 запросов в секунду. Неплохо, очень неплохо.
MySQL: 1490 запросов в секунду. Вот тебе и дефолтные настройки :). Стоит отметить, что изначально было 9 запросов в секунду. Помогла замена обращения к localhost на 127.0.0.1. Насколько знаю, связано с активным IPv6 в системе.
MongoDB: 3173 запросов в секунду. Замечательный результат. Хотя от NoSQL я ожидал большего.

Прямо скажем, сравнение не самое честное. Тест происходил на дефолтных настройках. Я не обладаю необходимыми навыками администрирования, чтобы выровнять настройки СУБД.
MongoDB, в первую очередь, ориентирована на скорость. SQLIte ориентирован на надежность. А PostgeSQL в дефолтной настройке ориентирован на минимум потребления ресурсов. Возможно, в этом и причина провала.
UPD: Мне тут по «большому секрету» подсказали, что PostgreSQL не любит переподключения. Поэтому я провел однопоточные тесты для каждой СУБД.
Тест замеряет время работы в однопточном режиме. 10000 операций, чистая БД. Операция вида 1 SELECT, 1 UPDATE и 1 INSERT в транзакции. Замер скорости в скрипте (как в 1м тесте), без времени подключения к БД.
Результаты следующие:
PostgreSQL: 1403. Рост в 7 раз. Что подтверждает нелюбовь PostgreSQL к переподключениям.
PostgreSQL (fsync = off): 1766. Рост на четверть относительно дефолтного режима. В многопоточном режиме прирост не проявился.
SQLite: 938. Странно, раньше 1500 было. Наверное, в тесте была ошибка.
MS SQL: 1993. Рост есть, но незначительный. Где-то на 40% (рост в 1,4 раза).
MySQL: 2514. Рост есть, в 1,7 раза.
MongoDB: 7603. Рост почти в 2,5 раза.

Результаты достаточно интересные. Настолько, что я решил сравнить производительность разных СУБД на сервере. Напомню, что используется Debian 6. На сервере стоят: SQLite (v3.7.3), PostgreSQL (v9.0.4), MySQL (v5.1.66). Все в дефолтной настройке. AB запускался локально, на сервере. 10000 запросов в 10 потоках.
Результаты:
SQLite: 174 запроса в секунду.
PostgreSQL: 104 запроса в секунду.
MySQL: 167 запросов в секунду.

Как видим, такого большого разрыва, как для локальной машины, в показателях нет. Но не стоит забывать, что на сервере используется SSD (пусть и не в “чистом” виде, а как элемент облачной СХД).

Как итог можно сказать, что связка PHP и SQLite вполне работоспособна для невысоко нагруженных проектов. Достаточно придерживаться некоторых простых правил:

1. Используем WAL-режим журналирования.
2. Не забываем устанавливать Busy Timeout.
3. Запись объединяем в транзакции. Причем не простые, а “BEGIN IMMEDIATE”.

Если же проект отнести к “небольшим” нельзя, то использование SSD для базы вполне может помочь и здесь.

Если же говорить о Hi-Load, то ребята, этим занимающиеся, знают что им делать и без моих советов.

Если же сравнивать SQLite с другими СУБД, то они обладают сравнимой производительностью на настройках по умолчанию. Во всяком случае при использовании SSD диска.
Вместе с тем, простота настройки и администрирования (ничего не надо настраивать и администрировать), простота переноса на другой сервер (простым копи-пастом) дают некое преимущество для SQLite. В первую очередь для разработчиков. Для работы SQLite с PHP ничего, кроме самого PHP и не надо.

источник