IPB

Здравствуйте, гость ( Авторизация | Регистрация )



6 страниц V  « < 4 5 6  
Reply to this topicStart new topicGo to the end of the page
> Делаю сайт, Впервые!
indеx
сообщение 17.08.2017 - 13:36
Сообщение #51


Авторитетный
******

Текущее настроение:

Вст. ник | Цитата

Группа: Супер Стар
Сообщений: 2750
Регистрация: 29.12.2009
Пользователь №: 33839

Награды: 15
Подарки: 28

Пол: М


Репутация:   250  

Выяснилось, что совет по сохранению конфигурации iptables, описанный в сообщении http://tochek.net/index.php?showtopic=5999...t&p=2436477, а также в конце сообщения http://tochek.net/index.php?showtopic=5999...t&p=2441008, не всегда работает. То есть, новые настройки после перезагрузки не восстанавливаются. Попробовал найти решение самостоятельно и нашёл способ, который сработал.
В каталоге /etc/iptables есть файл rules.v4, в котором прописаны правила iptables. И по всей видимости, именно этот файл используется при восстановлении настроек после перезагрузки. Пробуем сохранить наши настройки в этот файл:
Код
iptables-save > /etc/iptables/rules.v4
а файл 0000-iptables.bash, созданный нами ранее в каталоге /etc/network/if-up.d, удаляем из этого каталога, как не прошедший проверку на надёжность.
Перезагружаем сервер:
Код
reboot now
и смотрим, восстановились ли правила:
Код
iptables -L -n --line-numbers
Да, все правила восстановились. Но вдруг они восстанавливаются не из этого файла, а откуда-нибудь ещё? Чтобы проверить это, давайте удалим переместим этот файл в другое место и перезагрузим сервер. После перезагрузки смотрим — правила не восстановились без этого файла. Значит, это точно тот самый файл. Возвращаем его на своё место /etc/iptables/rules.v4, перезагружаем сервер, проверяем правила и снова видим, что правила восстановились. Берём этот способ на вооружение.


--------------------


--------------------
Подарки: (Всего подарков: 28 )
Подарок
Подарил(а): льдинка
Подарок
Подарил(а): Апостол Иуда
Подарок
Подарил(а): льдинка




Go to the top of the pageGo to the end of the page
 
+Quote Post
indеx
сообщение 18.08.2017 - 19:14
Сообщение #52


Авторитетный
******

Текущее настроение:

Вст. ник | Цитата

Группа: Супер Стар
Сообщений: 2750
Регистрация: 29.12.2009
Пользователь №: 33839

Награды: 15
Подарки: 28

Пол: М


Репутация:   250  

Таким образом получается, что у нас в памяти сервера работают несколько процессов PHP — для каждого сайта свой процесс. Или даже не один? Хм, интересно, а сколько? Давайте посмотрим...
Есть одна команда:
Код
ps aux --sort -rss
которая выводит на экран список всех процессов:
» Кликните сюда для просмотра оффтоп текста.. «
И в этом списке мы можем видеть количество процессов, сколько они занимают памяти и на сколько загружают процессор. Этот список, по всей видимости, упорядочен по объёму занимаемой памяти. И самый большой объём, как мы видим, занимает наша СУБД MySQL20% оперативки. Всего на сервере 1 Гб памяти, значит MySQL занимает 200 МБ. Также мы видим, что для одного сайта выделено от 3 до 6 процессов PHP. Это как раз те значения, что мы прописывали в файлах в каталоге /etc/php/7.0/fpm/pool.d. Этот список неполный, там ниже есть ещё процессы, которые занимают меньше памяти. Но сколько же памяти занимают все процессы вместе? Им вообще хватает одного гигабайта, или мало? Давайте узнаем... Есть такая команда:
Код
free
которая выводит на экран кратко:
Код
              total        used        free      shared  buff/cache   available
Mem:        1016028      364904      131664       49552      519460      413600
Swap:             0           0           0
Где мы видим, что всего — 1016028, а используется 364904. Но свободно почему-то всего-лишь 131664. А доступно почему-то 413600. Видимо, доступное уже не считается свободным. А кроме того, есть ещё слово Swap, по всей видимости означающее, что бывает файл подкачки, но на данный момент он не используется (размер 0).
А давайте, чтобы не рисковать переполнением памяти, попробуем подключить к оперативке ещё и файл подкачки. Сколько у нас там свободного места на диске? Проверяем командой:
Код
df
Смотрим на экран:
Код
Filesystem     1K-blocks    Used Available Use% Mounted on
udev              487848       0    487848   0% /dev
tmpfs             101604   10756     90848  11% /run
/dev/vda1       10286264 4727292   5018428  49% /
tmpfs             508012       0    508012   0% /dev/shm
tmpfs               5120       0      5120   0% /run/lock
tmpfs             508012       0    508012   0% /sys/fs/cgroup
tmpfs             101604       0    101604   0% /run/user/1000
То есть, из 10 Гигабайт на диске, у нас свободно половина — 5 Гб. Отлично, тогда давайте к 1 Гб оперативки подключим ещё 1 Гб файлом подкачки, что увеличит память в 2 раза. Вводим команду создания файла:
Код
fallocate -l 1G /swapfile
Проверяем — в корне должен появиться файл swapfile. Теперь превращаем этот файл в файл подкачки... Сначала отрубаем к нему доступ всем пользователям, кроме root:
Код
chmod 600 /swapfile
Теперь внутри этого файла создаём файловую систему, используемую специально для файлов подкачки:
Код
mkswap /swapfile
И теперь, собственно, включаем его как файл подкачки:
Код
swapon /swapfile
Проверяем, что изменилось у нас со свободным местом:
Код
free
Видим явные изменения:
Код
              total        used        free      shared  buff/cache   available
Mem:        1016028      367328      125272       50016      523428      410668
Swap:       1048572           0     1048572
Теперь наш файл используется в системе для расширения оперативной памяти. Но если оставить так, то это дело будет работать только до перезагрузки сервера. А чтобы работало и после перезагрузки, нужно в конец файла /etc/fstab добавить одну строку:
Код
/swapfile none swap sw 0 0
И сохранить файл.
После этого мы перезагружаем сервер, убеждаемся, что после перезагрузки файл подкачки тоже используется, и радуемся, что теперь-то у нас точно хватит памяти для всех процессов на сервере.

Продолжение следует...


--------------------


--------------------
Подарки: (Всего подарков: 28 )
Подарок
Подарил(а): льдинка
Подарок
Подарил(а): Апостол Иуда
Подарок
Подарил(а): льдинка




Go to the top of the pageGo to the end of the page
 
+Quote Post
indеx
сообщение 17.10.2017 - 20:27
Сообщение #53


Авторитетный
******

Текущее настроение:

Вст. ник | Цитата

Группа: Супер Стар
Сообщений: 2750
Регистрация: 29.12.2009
Пользователь №: 33839

Награды: 15
Подарки: 28

Пол: М


Репутация:   250  

Небольшая заметка.

По умолчанию PHP обрабатывает скрипты только в таких вставках:
Код
<?php ... ?>

Но для удобства и для эстетики лично мне хочется использовать вставки вот такие:
Код
<? ... ?>
Чтобы такие вставки работали, нужно в файле php.ini найти строку:
Код
short_open_tag = Off
и заменить её на:
Код
short_open_tag = On
Само собой, после этого нужно перезапустить PHP:
Код
systemctl restart php7.0-fpm


--------------------


--------------------
Подарки: (Всего подарков: 28 )
Подарок
Подарил(а): льдинка
Подарок
Подарил(а): Апостол Иуда
Подарок
Подарил(а): льдинка




Go to the top of the pageGo to the end of the page
 
+Quote Post
indеx
сообщение 25.10.2017 - 16:03
Сообщение #54


Авторитетный
******

Текущее настроение:

Вст. ник | Цитата

Группа: Супер Стар
Сообщений: 2750
Регистрация: 29.12.2009
Пользователь №: 33839

Награды: 15
Подарки: 28

Пол: М


Репутация:   250  

Компьютерная техника обычно работает чётко, строго по инструкциям и программам. Но всё-таки иногда случаются непредвиденные ситуации, в результате которых информация на сервере может частично пропасть. Особенно ценной является информация, хранящаяся в базе данных сайта. Например, все наши сообщения на этом форуме хранятся в базе данных сайта tochek.net. И если часть сообщений однажды вдруг пропадёт, то это будет очень печально. Такое, кстати, однажды было на этом форуме. В разделе "Непознанное -> Прочие религии и учения" модератор Сладкая Смерть случайно удалила все темы. ag.gif А потом заполняла этот раздел вновь созданными с нуля темами. ab.gif Чтобы такого не происходило, системные администраторы сайтов регулярно делают так называемые дампы базы данных. То есть, сохраняют всю информацию из базы данных в файл, чтобы потом её можно было восстановить из этого файла. База данных коммерческого сайта, хранящая записи о движении денежных средств, ещё более ценна, поэтому её сохраняют обычно каждый день. Мы можем делать это вручную с помощью программы MySQL Workbench, как уже было описано выше, но гораздо удобнее, чтобы это делалось автоматически. А для этого нужна командная строка. Ещё один минус сохранения базы данных через программу Workbench заключается в том, что я подключаюсь ей через SSH-туннель, который из-за своей шифровки сильно снижает скорость передачи данных по сети, и большая база данных будет сохраняться таким способом очень долго. В командной же строке сохранение идёт не через сеть, а в пределах этого же сервера — из базы данных в файл, что проходит намного быстрее при сохранении больших объёмов информации.
Короче говоря, нам нужно уметь делать в командной строке две операции: 1) сохранение БД в файл, 2) восстановление БД из файла.

Сохранение базы данных в файл.
В командной строке сервера пишем:
Код
mysqldump -R -u admin -p dbname > dump.sql
  • где:
    -R — параметр, указывающий, что в файл нужно сохранять не только таблицы и view, но и хранимые программы (процедуры и функции);
    admin — имя пользователя СУБД MySQL, имеющего права администратора, ибо только он имеет право читать содержимое хранимых функций и процедур (иначе хранимые программы не сохранятся в файл);
    dbname — имя базы данных, которую мы сохраняем в файл;
    dump.sql — имя файла, куда мы сохраняем базу данных (файл с этим именем будет создан в текущем каталоге).
затем нажимаем Enter, вводим пароль пользователя username и ещё раз Enter.
Ждём пару секунд и видим, что база данных dbname сохранилась в файле dump.sql. Файл текстовый, его можно открыть и увидеть, что он написан на языке SQL. Размер этого файла получается большой, поэтому его обычно архивируют.


Восстановление базы данных из файла.
Если сохранение БД выполняется одной командой, то для восстановления необходимо сначала войти в командную строку mysql. Для этого в командной строке сервера пишем:
Код
mysql -u admin -p
затем нажимаем Enter, вводим пароль пользователя admin (имеющего права администратора) и ещё раз Enter.
Это мы вошли в командную строку mysql.
Сначала выбираем базу данных, в которую мы будем восстанавливать данные из файла:
Код
use dbname2
и нажимаем Enter. СУБД ответит ниже: Database changed.
А теперь, собственно, восстанавливаем:
Код
source dump.sql
По экрану побегут строчки, мы дожидаемся окончания их бега и всё, база данных восстановлена.
Но это всё равно вручную. А для автоматизации нужно использовать программу Cron, работа с которой описана выше. Только пароль в этом случае вручную уже не введёшь, и его придётся прописывать в файле, а это потенциально опасно, если сервер физически находится не у меня. И это дилемма. Если автоматизированно, то могут пароли из файлов достать. Если вручную изредка, то можно потерять новые данные из-за какого-нибудь сбоя. Если вручную каждый день, то это лень. ca.gif В общем, пока сохраняю вручную изредка, а дальше видно будет...

Сообщение отредактировал indеx - 25.10.2017 - 16:05


--------------------


--------------------
Подарки: (Всего подарков: 28 )
Подарок
Подарил(а): льдинка
Подарок
Подарил(а): Апостол Иуда
Подарок
Подарил(а): льдинка




Go to the top of the pageGo to the end of the page
 
+Quote Post

6 страниц V  « < 4 5 6
Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 




> Статистика
Board Stats

Яндекс цитирования         


Текстовая версия Сейчас: 20.11.2017 - 20:23