ponaehal, для сферичского сервера mysql в вакууме: файл ibdata один большой и у него почти нет шансов быть закешированным ОС, файлы таблиц намного меньше поэтому вероятность того что файл таблицы будет закешированн ОС и этот файл доживет в кеше до следующего запроса к нему намного больше, если хотябы одно чтение было из кеша а не с диска - уже хорошо.
ponaehal, для хранилища innodb можно это настроить. Более того если у вас больше одной базы с innodb к которой идут обращения то innodb_file_per_table=1 немного увеличивает производительность.
Важно: innodb_file_per_table=1 нужно включать до создания таблиц.
Алексей Коновалов, Вы добавляете еще одну сущность которая манипулирует данными, раньше у вас был только ваш код, теперь у вас еще и триггер про кторый надо помнить. (например обычный бекап базы при помощи mysqldump не забекапит тригер, так как нужно явно указывать ключ --routines)
Правильнее делать INSERT в posts и UPTATE users.posts.
Андрей Пронин,
TCP/IP может оказаться недостаточно. (понимаю что аргумент таксебе поэтому ниже примеры)
а) Вам могут встретится сети не базируещиеся на IP чтото древнее типа IPX или спецфическое- например промышленные сети типа Profibus
б) Возможно вы будете сами разрабатывать протокол обмена данными и тут тоже вам пригодится модель OSI.
Андрей Пронин,
Когда странная проблема с сетью и в этой сети есть все что угодно - аппаратные фаерволы, туннели, гипервизоры с кучей виртуальных машин а у каждого внутри свой dhcp, балансировщики нагрузки и бог весть что. И проверять все приходится с канального уровня по прикладной. - если вы незнаете моджель OSI то вы не будете знать что проверять, приведу неполный список того что иногда приходится проверять:
Соответвие mac адресов и ip адресам на коммутатарах, ассимитричную маршрутизацию, размер MTU, правила на аппаратных фаерволах и тд.
xmoonlight,
По вашему пункту 2, прочтение статьи у меня оставило смешанные чуства, там есть как полезные вещи так вещи которые могут быть опасными:
1 - при большом колве коннектов имеет смысл вобще отказаться от conntrack так как он может закончится, и потребляет память.
2 - засунуть гору параметров в sysctl.conf не понимая их смысла и влияния - тоже очень опасно, а в статье описания к ним нет.
Tomatos
1. я не против других мнений, просто делюсь своим опытом, если у вас другой опыт то поделитесь ситуациями и примерами из жизни думаю все найдут в них чтото полезное.
2. Капитан Очевидность, позвольте подавть вам вашу фуражку, а если серьйозно - если на сервере вобще нечего делать из под обычно пользователя, а из под рута вам сейчас придется сделать 20-30 команд, то вы серйозно каждый раз будете вводить пароль ? и думаете это както сильно уменьшит вероятность ошибки ? а если вы целый день рабтаете с такими серверами ? я так не думаю и я ценю свое время.
3 для этого есть другие решения где в лог просто пишется кто что запускал и не важно что разные люди просто зашли по ssh сразу на юзера root. так что ненадо пытатся решать задачи логирывания и аудита при помощи sudo.
З.Ы. есть типы задач и работ где sudo будет только мешать, а если челоек выполняет команды от root не думая то там sudo не спасет.
Зависит от логики приложения, статус unread можно ставить не только по сообщению но и по дате: чтото вроде unread = where message post date >= $last viewed date и это для каждого чата, по мере пролистывания сообщений дата меняется. Возможно есть еще варианты как это реализовать (я не програмист или архитектор, просто много ковырялся в разных апликейшонах)
alexq2, это бэкапный сторедж - делловский оч толстый сервер и дисковая полка(возможно две), пучок рейд контроллеров в жбоде, поверх zfs ный рейд, данные туда льются по нфс или експортируется блочное устройство по iscsi, изделие не мое - им занимается соседняя команда.
По хорошему нужно обновлять все, если нет явных противопоказаний (для этого нужно читать чендж логи и или тестирывать все перед обновлением). Понятно что все ченджлоги для всего читать долго поэтому стоит читать их как минимум для критических сервисов например на хостинге это apache/nginx php mysql, Ну и глобально чтобы чтото сильно ломалось при обновлениях случай очень редкий + вернуться на предыдущую версию зачастую не проблема.(кроме случаев когда вы пару лет не обновлялись)
возможно в разных ОС или версиях curl разный вывод, но curl всеравно использует внешнею библиотеку скорее всего openssl (в обльшинстве linux дистрибутвах) и поддержка версий TLS в первую очередь зависит именно от нее, стоит посмотреть версию этой библиотеки и ее возможности.