nirvimel

ОБщий принцип размещения файлов такой -
На SSD размещается информация с которой часто и много работают - читают, пишут изменяют.
Т.е своп, профили пользователей, временные файлы - в первую очередь. Ну и желательно систему.
На HDD размещается информация которую больше хранят чем используют, либо скорость работы с которой не критична - архивы, видео, фото, и прочие объемные и относительно редко используемые файлы.

В итоге на SSD однозначно -
/tmp
/var
/lib
/root
А вот
/home - тут надо смотреть, по идее тоже весь на SSD надо, но если там есть тяжелая статика, то ее желательно вынести на HDD.

Много споров, о том стоит ли отключать журналирование

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

Желательно проверить работу TRIM, не забивать диск под завязку.
Если предполагается регулярная запись на SSD больших объемов информации желательно оставить over provisioning, то же самое если TRIM не работает.

Своп не нужен, ОЗУ хватает.

Достаточный объем памяти гарантирует то что своп будет использоваться редко и мало. Но ни в коем случае не отменяет его необходимости. Своп нужен при любом количестве памяти.

Баг - это когда вместо скидки к цене делается надбавка. А ишью - это когда у цены со скидкой слишком много цифр после запятой и она не влазит в отведенный ей контрол.

Если событие происходит быстрее, чем за 150-200 мс - человеку кажется, что событие произошло до его действия.
Если между действием пользователя и получением результата проходит больше 0.5-1 с., велика вероятность, что это начнёт раздражать пользователя.
Ваше время генерации совершенно ОК, если речь идёт о >=99% кванитили. Убедитесь только в том, что ваши основные пользователи находятся в восточной Европе, чтобы роутеры+скорость света до Америки/Азии не накладывали большую дополнительную задержку и что JS на клиенте не очень тяжёлый, чтобы задержка на стороне клиента для рендера контента тоже была не очень большой.

Для анализа сетевой проблемы есть две утилиты - traceroute и mtr.

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

Может кто поделится своими "изобретениями"?

потому

исправить - как написал Roman Kitaev
или другими извращениями

Что изучить для фриланса?

Подключиться к субд снаружи и загрузить файл через штатные средства

filesize, fopen, fseek, fgets - должны помочь пропускать уже обработанные строки.
1. Считываете по-символьно строку за строкой, всегда определяете максимальное время обработки одной строки.
2. Как только превышен максимальный лимит времени минус 3*макс. время одной строки (3-й запас), то запоминаем позицию и останавливаем чтение из файла.
3. Позицию для продолжения - передаём (возвращаем) в ajax (в браузер)
4. Используя эти параметры, при запуске скрипта вызываем seek на стартовую позицию и продолжаем обработку файла.

Если СУБД закоммитило в БД запись частично, то в топку такую СУБД

Ява тут не при чем. Тебе нужно лезть в код своей СУБД и смотреть как там все реализовано

ПС лучше сейчас перейти на постгрес, чтоб не убить себя фейспалмами

Для Python есть PyQt4(5), в ней можно делать все что угодно, включая использование css для настройки элементов GUI.
По умолчанию PyQt выглядит нативно для операционной системы.

Определение красивый UI, очень размыто. Луший вариант это когда приложение не выделяется от приложений установленых в систему.

Вот простой пример как использовать CSS для кнопки:

from PyQt5 import Qt


class Widget(Qt.QWidget):

    def __init__(self):
        super().__init__()
        layout = Qt.QVBoxLayout(self)

        button1 = Qt.QPushButton("Button 1")
        button2 = Qt.QPushButton("Button 2")

        layout.addWidget(button1)
        layout.addWidget(button2)

        button1.setStyleSheet("""
        QPushButton {
            background-color: green;
            border-style: outset;
            border-width: 2px;
            border-radius: 10px;
            border-color: beige;
            font: bold 14px;
            min-width: 10em;
            padding: 6px;
            }
        QPushButton:pressed{
            background-color: #4CAF50;
            color: white;
            border-color: black;
            border-style: inset;
            }
        """)


if __name__ == '__main__':
    app = Qt.QApplication([])

    w = Widget()
    w.show()
    app.exec()

Софт - стандартное средство архивации windows.
Рекомендую следующую схему - один диск для архивации подключен постоянно, на него осуществляется регулярная архивация, запускаемая по расписанию ежедневно или еженедельно.
Задание архивации должно работать под специальным пользователем имеющим полные права на чтение всех данных которые нужно архивировать, и права на чтение и запись архивного диска.
Кроме этого пользователя ни у кого не должно быть прав на чтение и запись архивного диска, даже у администратора.

Второй диск подключать раз в месяц или около того и запускать архивацию вручную.

Помимо ТЗ, законом охраняется так же фирменное наименование компании (ООО). Поэтому самый простой способ защитить домен с хорошим названием - создать юр.лицо с таким названием, так как по ГК РФ это наименование охраняется, соответственно имеет приоритет перед доменом. А вот сравнивать приоритет ТЗ и ФН - достаточно сложно. Думаю, судебная практика будет на стороне того, у кого есть что-то закрепленное законом (ФН или ТЗ) и имеющее более раннюю дату регистрации.

Вы так же можете создать юр.лицо и отжимать домен с таким названием, и это уже не фантастика, к сожалению.