Недавно понадобилось произвести диагностику питания, для того чтобы понять по какой причине не запускается машина. К сожалению, в интернете оказалось мало годных статей на эту тему, поэтому пришлось самому лезть в даташиты.
Эта статья является выжимкой из моих изысканий и надеюсь поможет кому-нибудь, когда им придется заниматься тем же самым.

Дисклеймер номер раз: Данная статья относится только к обычным блокам питания стандарта ATX, она не относится к проприетарным стандартам блоков (например как у старыx рабочиx станциях DELL или SUN), использующим другую распиновку ATX-коннектора. Внимательно сверьтесь со схемой и убедитесь в том, что ваш блок питания является стандартным прежде чем проводить диагностику, во избежании причинения вреда вашему компьютеру.

Дисклеймер номер два: Вы должны понимать что вы делаете и соблюдать технику безопасности, в том числе электростатической (в т.ч. работать в антистатическом браслете). Автор не несет ответственности за порчу оборудования или вред здоровью вследствие несоблюдения или незнания техники безопасности и принципов работы устройства.

Перейдем к теории:

Стандарт ATX имеет 2 версии — 1.X и 2.X, имеющие 20 и 24-пиновые коннекторы соответственною, вторая версия имеет 24-x 4 дополнительных пина, удлиняя тем самым стандартный коннектор на 2 секции таким образом:


Прежде чем мы начнем, расскажу про “правила большого пальца” по отношению к неисправностям:
1) Проблемную материнскую плату легче заменить чем починить, это крайне сложная и многослойная схема, в которой разве что можно заменить пару конденсаторов, а обычно это проблемы не решает.
2) Если вы не уверены в том что вы делаете, то не делайте этого.

В этом топике я хотел бы рассказать о том, как устроена кассандра (cassandra) — децентрализованная, отказоустойчивая и надёжная база данных “ключ-значение”. Хранилище само позаботится о проблемах наличия единой точки отказа (single point of failure), отказа серверов и о распределении данных между узлами кластера (cluster node). При чем, как в случае размещения серверов в одном центре обработки данных (data center), так и в конфигурации со многими центрами обработки данных, разделенных расстояниями и, соответственно, сетевыми задержками. Под надёжностью понимается итоговая согласованность (eventual consistency) данных с возможностью установки уровня согласования данных (tune consistency) каждого запроса.

NoSQL базы данных требуют в целом большего понимания их внутреннего устройства чем SQL. Эта статья будет описывать базовое строение, а в следующих статьях можно будет рассмотреть: CQL и интерфейс программирования; техники проектирования и оптимизации; особенности кластеров размещённых в многих центрах обработки данных.

Привет, хабр!

Сегодня я хотел бы рассказать о интересной и полезной фиче. Имя ее — Библиотека контейнеров. Это не одна, а целая группа полезных фич. А их назначение — организация и обработка групп элементов. Звучит интересно, да? Сейчас рассмотрим поближе — добро пожаловать под кат.

Введение

С момента написания мной предыдущей статьи по оптимизации этой связки прошло довольно много времени. Тот многострадальный Pentium 4 c 512Мб памяти, обслуживающий одновременно до тысячи человек на форуме и до 150,000 пиров на трекере уже давно покоится на какой-нить немецкой, свалке, а клуб сменил уже не один сервер. Всё сказанное в ней всё ещё остаётся актуальным, однако есть вещи которые стоит добавить.
Статья большая, так что будет поделена на логические блоки:

0. Зачем вообще что-то оптимизировать?
  
1. Оптимизация ОС (FreeBSD)
  1.1 Переход на 7.х 
  1.2 Переход на 7.2
  1.3 Переход на amd64
  1.4 Разгрузка сетевой подсистемы
  1.5 FreeBSD и большое кол-во файлов
  1.6 Softupdates, gjournal и mount options
  
2. Оптимизация фронтенда (nginx)
  2.1 Accept Filters
  2.2 Кеширование
  2.3 AIO
  
3. Оптимизация бэкенда
  3.1 APC
  3.1.1 APC locking
  3.1.2 APC hints
  3.1.3 APC fragmentation
  3.2 PHP 5.3
  
4. Оптимизация базы данных
  4.1 MySQL 
  4.1.1 Переход на 5.1
  4.1.2 Переход на InnoDB
  4.1.3 Встроеный кеш MySQL - Query Cache
  4.1.4 Индексы
  
4.2 PostgreSQL
  4.2.1 Индексы
  4.2.2 pgBouncer и другие.
  4.2.3 pgFouine
  
4.3 Разгрузка базы данных
  4.3.1 SphinxQL
  4.3.2 Не-RDBMS хранилище
  4.4 Кодировки
  4.5 Асинхронность
  
Приложение. Мелочи.
  1. SSHGuard или альтернатива.
  2. xtrabackup
  3. Перенос почты на другой хост
  4. Интеграция со сторонним ПО
  5. Мониторинг
  
 6. Минусы оптимизации

Непрерывная интеграция (англ. Continuous Integration) — это практика разработки программного обеспечения, которая заключается в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем. В обычном проекте, где над разными частями системы разработчики трудятся независимо, стадия интеграции является заключительной. Она может непредсказуемо задержать окончание работ. Переход к непрерывной интеграции позволяет снизить трудоёмкость интеграции и сделать её более предсказуемой за счет наиболее раннего обнаружения и устранения ошибок и противоречий.

В этом топике мы в общих чертах рассмотрим процесс реализации непрерывной интеграции на примере TeamCity Enterprise 6.0 EAP (build 15400) и обратим внимание на применении инструментов рассмотренных в прошлой теме: Обеспечение качества программного продукта.

Дисциплина «Метрология программного обеспечения» входит в учебный план подготовки дипломированных специалистов по направлению 654600 — «Информатика и вычислительная техника» по специальности 220400 — «Программное обеспечение вычислительной техники и автоматизированных систем». Дисциплина изучает проблемы оценки метрических характеристик качества ПО на этапах от разработки спецификаций до завершения отладки и тестирования программного продукта. В курсе рассматриваются критерии, характеристики и метрики качества ПО; особый упор делается на характеристики корректности, надежности и сложности программ. Изучаются формальные модели и методы оценки как статических, так и динамических характеристик качества ПО, позволяющие на различных стадиях разработки выявлять просчеты и дефекты программного изделия. Рассматриваются инструментальные средства поддержки и автоматизации измерения характеристик ПО.

Далее по тексту будет находится краткий обзор инструментов с помощью которых можно анализировать различные характиристики в приложениях созданных на PHP. Данный материал появился на свет в результате некоторых экспериментов в области непрерывной интеграции, и должен был являться частью статьи про непрерывную интеграцию (спойлерить пока не буду, боюсь сглазить) все в том же РНР, но я решил все-таки выделить его в самостоятельный обзор, так как возможно, в последующих статьях я буду ссылаться на него, а так же надеюсь узнать об аналогичных инструментах еще не попавших мне на глаза. Некоторые инструменты уже были рассмотрены достаточно подробно, но тем не менее полного списка всех доступных еще не было.

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

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