Довольный Айтишникъ

Куда пропало еще 2 ГБ оперативной памяти?

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

Как правильно настроить файл подкачки в моём случае?

Размер по выбору системы, размещение на SSD.

Почему сильно загружается диск?

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

Нормально ли его хранение не на системном диске?

Нормально. Но разумеется это должен быть SSD диск.

Как быть с сильной нагрузкой диска (грузится до 100% и начинаются жуткие лаги и фризы)?

Устранить нагрузку, либо поставить более производительный диск.

XML парсим любой библиотекой. Получаем дерево разбора.
https://pep8.ru/doc/dive-into-python-3/14.html
Дальше начинаете обходить дерево и для каждога узла(node) проверять подходит ли он вам.
https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D1%85%D...
В функции проверки и должна быть вся магия. Возможно вы сможете придумать эвристическое правило от разных параметров. Например:
*путь от корня (root/part/segment/item)
*имя тега
*значения параметров тега
*имена тегов-детей
*...
При необходимости можно пытаться ускорить процесс, если о данных что-то известно. Так можно не обходить все дерево, а отбрасывать его части если мы поняли что это не то что нам нужно.

Если данных очень много и вариативность очень большая (например ищем рекламу на веб страницах) можно заняться машинным обучением. Это отдельная сложная тема выходящая за рамки вопроса.

Определитесь, в чем ваш конечный вопрос.
Если это "можно ли написать back end не на PHP?", то ответ - "безусловно, можно".
Если это "на сколько плох PHP относительно других языков для этой задачи?", то ответ - "для вас - без разницы".
Если это "можно ли вообще не уметь программировать и сделать сайт?", то ответ - "можно, используя конструкторы, только он будет весьма типовым и шаблонным".
Если это "проще ли вам, не умея программировать, будет научиться это делать на других языках вместо PHP?", то ответ - "нет, не будет проще".

Ну и, как всегда, "учить" (тупо запоминать) - бесполезно. Нужно "изучать" (разбираться и понимать).

SELECT DISTINCT order_id FROM TableName WHERE item_id = 101 OR item_id = 102

к которому относятся оба item

SELECT DISTINCT TableName_101.order_id
  FROM TableName AS TableName_101 
    INNER JOIN TableName AS TableName_102 ON TableName_101.order_id = TableName_102.order_id
  WHERE (TableName_102.item_id = 102) AND (TableName_101.item_id = 101)

osql -S [Server] -E -Q "SELECT * FROM [Database].dbo.[Table]" > text

Оу...какие наивные способы, видимо все с этого начинали =)

Какая у тебя хоть тематика сайта?
Зачем людям заходить на твой сайт?
Какой контент будет ждать людей на сайте?
Для чего, ты делаешь сайт?

__

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

Люди начнут ходить к тебе на сайт лишь в одном из 2 случаев:

- у тебя на сайте будет какая-то крутая информация, за которой люди сами будут к тебе приходить (причем сайт и формат информации будет такой, что поисковики поставят выше сайтов твоих конкурентов с такой же информацией)

- ты начнешь загонять трафик на свой сайт в промышленном масштабе (т.е. платным способом). И тебе будет какой-то профит от того, что эти люди придут на твой сайт. Т.е. можно сделать сайт о котиках, заказать рекламы на миллион, к тебе придет условно 100к людей (любителей котиков), посмотрят твой сайт и уйдет. В итоге, ты потерял миллион, но ничего не заработал.
___

Как раскрутить сайт бесплатно? Легко.

• Делаем хороший качественный сайт.
  
• Делаем ему seo-оптимизацию внутренних факторов.
  
• Составляем матрицу запросов, которые тебя интересуют.
  
• Добавляем на сайт качественный уникальный контент, который совпадет с матрицей.
  
• Набираем порядка 600-800 единиц материала (причем надо добавлять его с переодичностью 1 материал, раз в 1-3 дня).
  
• Какой-то из материалов будет попадать в топ-выдачи по принципу тестовой ранжировки
  
• Получаем какой-то трафик (нужный, полезный, монетизируемый - а фиг его знает =)
  

Технически можно и так, и сяк. Но, как всегда, есть нюансы, на которых и сыпется большинство советчиков (в том числе в этом треде).

Если у вас только сайт на домене, максимум почта на других портах, и даже CDN не используется - можете спокойно использовать основной домен без www. Если у вас сайт многоязычный, и языки размещены на поддоменах - тогда тоже без www. Если же у вас есть и другие ресурсы в домене, например:

www.example.com - публичный сайт
developers.example.com - публичный сайт инструментов для разработчиков
api.example.com - какой-нибудь публичный АПИ
cdn.example.com - поддомен content delivery network (можно много - cdn1, cdn2 итд)
docs.example.com - публичная документация
help.example.com - публичная справка
support.example.com - публичная служба поддержки
dev.example.com - закрытая, непубличная копия сайта, стейджинг
hr.example.com - закрытая, непубличная часть, внутренние ресурсы компании для сотрудников
mail.example.com - технический субдомен для почты
webmail.example.com - веб-морда для почты (может быть как публичной, так и открытой для отдельных IP, доступ по VPN и тд)
vpn.example.com - чисто технический поддомен для проксирования трафика через VPN компании
ns1.example.com - поддомен для своего сервера имен (ns1/ns2/ns3 или primary/secondary и тд)

... и так далее. Таких поддоменов может быть очень много, и у каждого своя, совершенно изолированная кухня. Так вот, если использовать для публичного сайта домен без www, то все его куки будут распространяться на все поддомены. А это плохо. На современном сайте этих кук штук 10 минимум, большая часть из них совершенно не нужна, или даже откровенно лишняя на всех других поддоменах. В это же время, если вы используете www и хотите поделиться куками с него с другим поддоменом - это вполне возможно сделать, осознанно.

Кроме этого - с www намного удобнее работать на уровне DNS, если это CNAME. Записи типа А лучше ставить долгий TTL, а вот CNAME может иметь короткий и его можно перебрасывать в любой момент. Пошла DDoS-атака - в считанные минуты пустили трафик через гейт сервиса защиты от DDoS или выделенный файрвол (у который другие IP-адреса). Или балансировку нагрузки делать. При этом основной домен (origin) и его IP не меняется, почта не слетает, внутренние сервисы не слетают, АПИшки не падают и тд.

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

В общем, мое мнение - если у вас свой личный сайт или маленький сайтик маленького личного бизнеса, и рост до уровня когда понадобится куча поддоменов не планируется - тогда можете смело использовать без www. Если же продукт или сервис, бизнес который может вырости в что-то относительно крупное - стартуйте с www с самого начала, потом спасибо скажете.

1. Забор новостей - раз в N-минут. Можно по запросам, можно через cron.
2. После того, как забрали - кэшируем в файл ("сырой" кэш).
3. Затем - обрабатываем так, как нужно для вывода на сайте и сохраняем тоже в файл ("подготовленный" кэш).
4. Выводим - всегда из подготовленного файл-кеша (чтобы снизить нагрузку на хостинг).